Deal with out-of-sync room state, e.g. due to the last device logging out or leaving the room

[kegsay]

If you have 1 user with 1 device in a room, who then leaves the room, the room data in the DB will eventually go stale. However, if a new user then joins the same room, we will not reset our knowledge of room state (specifically, we discard the state in the sync response), and the room state can then diverge from the truth.

This isn't terribly dissimilar to when servers leave a room then rejoin the same room - they need to clear their DB when they leave.

[DMRobertson]

(Hashed out in #51 (comment) .)

It's true enough that room state in the proxy's DB can become out of date. (Indeed, we suspect that something like this has already happened---there are reports of old room names showing up.) However, deleting everything and starting from scratch is a little nuclear. Instead we can do the following.

• Whenever a poller sees a state block in an incremental sync v2 response, select the NIDs from the proxy database, for all event IDs in the state block.
• If they all have NIDs then the proxy's view of state is in sync with the HS, and all is well.
• Otherwise, prepend all events missing a NID to the timeline so that clients see the new state.
  • The timeline order will be wrong, but at least both the proxy and the client will now see up to date state---we've self-healed.
  • Is the order in which we do this important? E.g. if A invited B, should we show A's membership before B's?

Slogan: this makes the proxy "support gappy state" (but not gappy messages).

Other notes:

• This needs to all happen within a single database transaction.
  • do we also want to SELECT FOR UPDATE or similar?
• If we prepend events to timeline then we should write error log lines and make lots of noise in Sentry.