Consider dropping parts of the cached room state (and probably timeline too)

[KitsuneRal]

Accumulating the state quickly becomes a problem in case of communities like status.im, where newly registered users are automatically added to a bunch of rooms; as a result, there are 10 rooms with 6000 identical users each, and each of them stores its 6000 users independently.

[KitsuneRal]

As it stands, it's been alleviated quite some time ago by only using a single user object for a given MXID on a given Connection, no matter how many rooms they have joined. However, the state for each room includes all of its members, and switching to a given room means that all members of that room get loaded. This is not a (big) problem for any single room - and those members have to be pulled from the server anyway - but there's no way to collapse the state back once another room is opened (or some time thereafter). So yeah, if status.im were still using Matrix, there would be 10x6k state events loaded after opening 10 rooms - and these events cannot be deduplicated.

The same holds for message events - renamed the issue accordingly. In both cases it would be great to have some graceful way to drop parts of the state and timeline to ensure the memory footprint remains within some limits.