Faster joins: handle state which becomes invalid during de-partial-stating

[richvdh]

It's entirely possible that, during the process of de-partial-stating, we discover that we accepted some piece of state which we should not have done. (Simple example: it may turn out that the sender of a piece of state was not actually in the room at the time). We may have told clients about that state, and we may even have made other event-auth or access decisions based on it.

(I think this is also possible for backfilled events even in the non-faster-joins case, though a bit less likely.)

We should figure out the ramifications of that, and do something about it.

synapse/synapse/storage/state.py

Lines 532 to 549 in 7c6b220

	def must_await_full_state(self, is_mine_id: Callable[[str], bool]) -> bool:
	"""Check if we need to wait for full state to complete to calculate this state
	If we have a state filter which is completely satisfied even with partial
	state, then we don't need to await_full_state before we can return it.
	Args:
	is_mine_id: a callable which confirms if a given state_key matches a mxid
	of a local user
	"""
	# TODO(faster_joins): it's not entirely clear that this is safe. In particular,
	# there may be circumstances in which we return a piece of state that, once we
	# resync the state, we discover is invalid. For example: if it turns out that
	# the sender of a piece of state wasn't actually in the room, then clearly that
	# state shouldn't have been returned.
	# We should at least add some tests around this to see what happens.
	# https://github.com/matrix-org/synapse/issues/13006