Drop state_events and rejections tables

[richvdh]

Both state_events and rejections are tables which add a single piece of data to a subset of events (state_key and reason, respectively).

I believe this would better handled with nullable columns in the events table:

• state_events and rejections are never read from without a join to events, so we can save a join whereever we read from them
• it's not like adding the data to events is going to transform it from a small, cacheable table to something huge (so I don't expect much difference in the case where we don't join to rejections or state_events). In any case, when we look in events we normally want the rejection status too.
• obviously, populating three tables (and maintaining two extra indexes) is extra work to do when storing events.

However, getting from here to there is not an easy task by any means, and will take quite a bit of work to do in a way that doesn't break backwards compatibility. Here are the tasks as far as I can see them:

• disambiguate any references to the state_key column, in preparation for adding new columns to events: Disambiguate queries on state_key #11497
• Add state_key and rejection_reason columns to events, and populate them for all new events: Add state_key and rejection_reason to events #11792
• Add a background update to populate state_key and rejection_reason for all existing events: Bg update to populate new events table columns #13215
• Add some code which determines if the background update has completed, and if so, sets a flag which makes reads use the new columns instead of joining to the old tables.
• Add some more code which drops the old tables and stops populating them.

Each of those steps will require SCHEMA_VERSION and/or SCHEMA_COMPAT version updates to ensure that we never break compatibility with the previous Synapse release.

[richvdh]

It's no longer entirely clear that putting rejections into the events table is a good idea... it is possible for events to change rejection status (thanks to faster-joins) and in particular, different servers may have different perspectives on whether an event has been rejected or not. The implication is that, if we were to move to a model where a single event store could back multiple server deployments, the rejection status would have to go and live somewhere else.