Don't prune cache entries for get_or_create_notice_room_for_user

[babolivier]

Fixes #12686

Before this change, if the homeserver had an MAU limit set and time-based cache expiry turned on, Synapse would recreate a server notice room for every user who wouldn't sync for more than the configured cache entry TTL. If that TTL is low (e.g. 10min, for resource management reasons), this means loads of empty rooms can be created, filling up the homeserver's database with garbage.

The reason this happens is because, if an MAU limit is set, Synapse will check every time a user syncs whether the user should be notified about the limit being reached. This is done by calling get_or_create_notice_room_for_user, which looks up (and creates if necessary) a server notice room for the user, though without inviting them to it right away (so that the user is only invited when there's something to notify them about). That method is cached, but if the cache entry TTL is set to a low value and the user doesn't sync often enough the entry expires. At which point Synapse realises there isn't a room created by the server notice user with the user either invited or joined, and creates another.

Ideally we should persist the server notice rooms to the database rather than store them in an in-memory cache, because even with this change we're still creating new rooms after a restart. I didn't have the time to correctly think about every edge case of the database migration this would require (e.g. what to do about servers with existing server notice rooms but that don't have the feature enabled anymore, etc). Though this change will still be good to have in a world where we persist that data, so it's a good first step regardless. I'll open an issue about it so it's tracked somewhere.

[babolivier]

Actually I think the issue can be solved more simply in another way