Faster room joins: Device list cache not flushed when it is discovered that we incorrectly thought we shared a room with a remote user for some period in the past

[squahtx]

See the skipped TestPartialStateJoin/Device_list_tracking/Device_list_tracking_for_user_incorrectly_believed_to_be_in_room_when_they_rejoin_before_the_partial_state_join_completes complement test.

That test case is roughly:

1. A room starts with @charlie:remote, @derek:remote (moderator) and @fred:remote (admin)
2. @fred:remote leaves the room.
3. @alice:local partial state joins the room.
4. @elsie:remote joins the room.
5. @alice:local does a /keys/query request and the local homeserver caches @elsie:remote's device list.
6. @fred:remote "bans" @derek:remote, citing their join event as auth. The local homeserver does not know that @fred:remote is no longer in the room and accepts the event.
7. @derek:remote kicks @elsie:remote. The local homeserver incorrectly rejects the kick because it thinks @derek:remote has been banned. @elsie:remote stops notifying the local homeserver about device list updates.
8. @elsie:remote updates their device list.
9. @elsie:remote rejoins the room (or joins another shared room) and will notify the local homeserver about device list updates again.
10. The partial state join completes and @elsie:remote is discovered to not have been in the room / shared a room the whole time.
11. (bad) If @alice:local does a /keys/query request, a stale response is returned.

[squahtx]

After discussions with @erikjohnston, we've decided to deprioritize this edge case, since there are other known bugs in device list tracking when servers disagree about the members in a room.

[richvdh]

We think this is an edge-case, and no worse than existing bugs in device-list tracking (such as #13651), so not making it a priority for a fix.