send queue: handle redactions and get local echoes for redactions

For regular events and dependent events, the send queue can abort sending. If the underlying event was not being sent at the time of the abort request, then it's removed from the send queue's storage; otherwise, it results in a redaction event being sent to the server.

However, this is not infallible if a user tries to do it the other way, i.e. there was a reaction to an event, and they try to redact it and add it again. In this case, since the redaction isn't handled by the send queue, it may happen before or after the reaction has been added back, resulting in weird errors and situations (i.e. after removing and re-adding the reaction, it's not clear what's the final state of the reaction is in the room — and the timeline may show something that's temporarily incorrect, as a result).

Reusing the send queue for redactions would generally solve the problem of ordering here, and make it possible to ensure a total ordering for sending and redacting events in general. It could also mean that we may have local echo for redactions; this would require remembering what the redacted event was, for a short period of time, in case the redaction itself fails, but that's not intractable.

Start by tracing the send queue's handling of regular and dependent events, then compare that flow with the current redaction path. Investigate ordering when an event is redacted and re-added, including the failure case for the redaction; done means the issue's ordering and local-echo goals are addressed without leaving the final room state ambiguous.

Written by the indexing model from the issue text.