as /sync races with /send, and remote echo may happen first.
It's important for local echo that the pending redaction/relation
will also get attached to the remote echo before /send returns,
otherwise the remote echo would be "unannotated" until /send returns
as we'll need to await a bogus request first thing after opening the txn
funny enough, we originally made it sync to accommodate the same bug
in safari, but that didn't prevent any microtask being awaited
before scheduling a request in the calling code closing the txn.
We'll await a bogus request within the transaction class now so it
doesn't depend on the calling code
to have less state machines, and we are mostly interested in the
aggregate status of all attachments of an event
this will also drive updates through the pending events collection
that already exists rather than an extra observablevalue, so less
housekeeping to update the UI.
we were reading back a remote id of undefined because of this,
so when for some reason we never receive the message down from sync,
the pending message keeps sending on every load. The server ignores
the send though, because the transaction id is already used, and it returns
the remote id of the event that was already sent the previous time, but
as we were not storing this remote id, we'd just try again and again.
not receiving it through sync could have happened when we were sending a bunch of events
and then receiving (this is how we encountered this bug, while trying to repro another) the
response, but not yet the sync for the message that got wedged. Then we typed stuff on another client
so we would get a limited response for that room, and boom, we would not get the remote echo of the
event that was already sent (but because of this bug we didn't store the remote id) but no echo received yet (when we remove the pending event),
so it gets wedged!
