Invites are not always correctly handled over federation

[kegsay]

When a user joins a room they were invited to over federation, the join event can lack an unsigned.prev_content.membership == "invite". Instead, the prev_content is missing entirely. @DMRobertson and I theorise this is because the receiving server could not get the replaces_state event, because that would require a backfill.

Unfortunately, up until #333 the proxy was relying on this field being set. If it was unset, the invite would never be removed from the invites table.

When a client who is joined-but-still-has-the-invite requests information about this room, they end up with a blend of joined/invited data. Specifically, the invite_state is set to the stripped invite state events from the invite. This is bad because the presence of invite_state tells clients that the user is invited and not joined to the room. This could cause them to insert the room into a different place in the UI, or remove it entirely from the room list.

The fix in #333 means we no longer rely on this field, but there are still rooms which may be in this state in the database. We need to write a migration which:

• For each invite in the invites table (which shouldn't be too big relative to the number of joined rooms)
  • Is this user present in the current state of the room? NO: ignore (the proxy isn't in this room yet) YES:
  • Is the membership value invite? YES: ignore (someone else joined the room and the membership value is from their poller). NO:
  • Remove the invite from the invites table, as their current membership is something other than invite.