Fix #13856

`_invalidate_caches_for_event` doesn't run in monolith mode which
means we never even tried to clear the `have_seen_event` and other
caches. And even in worker mode, it only runs on the workers, not
the master (AFAICT).

Additionally there is bug with the key being wrong so
`_invalidate_caches_for_event` never invalidates the
`have_seen_event` cache even when it does run.

Wrong:
```py
self.have_seen_event.invalidate((room_id, event_id))
```

Correct:
```py
self.have_seen_event.invalidate(((room_id, event_id),))
```

Fix #13856

`_invalidate_caches_for_event` doesn't run in monolith mode which
means we never even tried to clear the `have_seen_event` and other
caches. And even in worker mode, it only runs on the workers, not
the master (AFAICT).

Additionally there is bug with the key being wrong so
`_invalidate_caches_for_event` never invalidates the
`have_seen_event` cache even when it does run.

Wrong:
```py
self.have_seen_event.invalidate((room_id, event_id))
```

Correct:
```py
self.have_seen_event.invalidate(((room_id, event_id),))
```

…rder) and persist in the oldest -> newest to get the least missing prev_event fetch thrashing

…not-being-invalidated

Copying what #13796
is doing

As mentioned by @erikjohnston,
#13865 (comment)

…lidated' into maddlittlemods/msc2716-many-batches-optimization

Conflicts:
	tests/storage/databases/main/test_events_worker.py

…into maddlittlemods/msc2716-many-batches-optimization

Conflicts:
	synapse/handlers/federation.py
	synapse/storage/databases/main/cache.py
	synapse/storage/databases/main/event_federation.py

…sertion event rejected

…in so everyhting is valid

We are going to lose the benefit of keeping the join noise out of the timeline.
And will probably have to hide "historical" state on the client.