The existing 'pendingEventOrdering'=='end' semantics had been substantially
broken by the introduction of timelines and gappy syncs: after a gappy
sync, pending events would get stuck in the old timeline section. (Part of
https://github.com/vector-im/vector-web/issues/1120).
This is some preparatory work for fixing up the problems with te timeline
ordering of unsent messages
(https://github.com/vector-im/vector-web/issues/1120). The functional changes
here should be minimal (bar an extra `Room.localEchoUpdated` when the local
echo is first added to the timeline).
Give `MatrixClient.sendEvent` its own entry point `Room.addPendingMessage`
instead of pushing it through `addEventsToTimeline`; this considerably
simplifies the implementation of the latter and also means that we can contain
the `_txnId` ming to MatrixClient.
Move the code which deals with a successful `/send` response from
`MatrixClient` into `Room.updatePendingEvent`, since it involves fiddling with
the innards of the Room.
Also adds a new EventStatus 'SENT' for events which have been successfully sent
but whose remote echo we still haven't received.
Transmission of encrypted messages was happening somewhat differently to
normal messages. In particular, we weren't copying the 'unsigned' field when we
got the remote-echo, which meant the 'sync' code didn't correctly match up the
echo with the original.
The separate codepath was becoming a thorn in my side, so fix things up to
bring it back in line.
We need to know about more transitions for local-echo status changes, so raise
localEchoUpdated events for each transition.
Fixes an issue where we weren't turning failed transmissions red, because the
timeline wasn't being updated.
We need to reset things at the UI level when we get a gappy sync, so give the
clients something to listen for.
Also add a bunch of tests for that bit of code.
Removing the last event in an EventTimeline (as we might, for instance, if it
was a local echo in an empty timeline) got us into a state where the baseIndex
would increment when adding events to the end of the timeline, causing much
confusion.
In order to resolve the conflict between local and remote read-receipts, try to
give precedence to the read-receipt which refers to the most recent event.
Also fix the read-receipt synthesis in _addLiveEvents so that it actually works
(drop the spurious MatrixEvent wrapper), and remove the synthesis in
recalculate() (which appears to be redundant).
David Baker