Faster joins: Creating events from local users: Track the set of forward safe chain events and use them as `prev_events`

[reivilibre]

Part of #12997.

Definitions

Safe chain: Chain of events created by local users since (and including) the join event sent in /send_join and up to and including the most recent event we have created.
Events in the safe chain are safe to divulge to remote homeservers that we believe to be in the room (i.e. because they're on the list that we received from partial /send_join)

Forward safe chain event(s): Set of locally-created events in the safe chain that do not have any locally-created events naming them as prev_events. Analogous to forward extremities; we'll use these for the prev_events of the next event we create.
Typically the most recent event we have created.

Open questions:

• can there be multiple 'forward safe chain events' — I think typically not, but @H-Shay's experiments with speeding up event creation at one point did support sending parallel events, so maybe we shouldn't design ourselves out of allowing that. (If so, does this mean we have to call the 'safe chain' the 'safe DAG' or 'safe connected component' or something..)?

What needs doing

• We need to track the set of 'forward safe chain events', initially just the join event that we create with /send_join, but updated as locally-created events are persisted, analogously to forward extremities. Probably not needed, at least not immediately.
• We need to use the forward safe chain events as prev_events for any events that we create locally.
  • Calculate the 'forward safe chain events' on the fly; e.g. get_prev_events_for_partial_join_room and WITH RECURSIVE query along event_edges, using the join event from partial_state_room as the backward point.

[reivilibre]

I think it's fair to say this is superseded by #14404! :)