this `real_users_cache` cache seems weird, and i have no idea what
prompted its creation upstream. perhaps they did this because
sqlite was very slow and their rocksdb setup is very poor, so
a "solution" was to stick member counts in memory.
slow iterators, scanning, etc do not apply to conduwuit where
our rocksdb is extremely tuned, and i seriously doubt something
like this would have any real world net-positive performance impact.
also for some reason, there is suspicious logic where we
overwrite the entire push target collection.
both of these things could be a potential cause for receiving
notifications in rooms we've left.
Signed-off-by: strawberry <strawberry@puppygock.gay>