* track notifTimelineSet on MatrixClient
* stop Rooms from tracking notifTimelineSet as they don't need to
* Implement client.paginateNotifTimelineSet
* make Events store their pushActions properly
* insert live notifs directly into the notifTimelineSet in /sync, ordering by origin_server_ts.
- to make way for alternative encryption algorithms. We now store an encryption
object for each room, rather than referring to sessionstore on each event.
Also a little light tidying to the jsdocs.
Make `MatrixEvent.event` contain the *encrypted* event, and keep the plaintext
payload in a separate `_clearEvent` property.
This achieves several aims:
* means that we have a record of the actual object which was received over
the wire, which can be shown by clients for 'view source'.
* makes sent and received encrypted MatrixEvents more consistent (previously
sent ones had `encryptedType` and `encryptedContent` properties, whereas
received ones threw away the ciphertext).
* Avoids having to make two MatrixEvents in the receive path, and copying
fields from one to the other.
*Hopefully* most clients have followed the advice given in the jsdoc of not
relying on MatrixEvent.event to get at events. If they haven't, I guess they'll
break in the face of encrypted events.
(The pushprocessor didn't follow this advice, so needed some tweaks.)
... and add some sanity checks
Two things here:
1. Clean up the Room API for adding new events to the timeline. Where before
we had addEvents and addEventsToTimeline, whose purposes were unclear, we now
have addLiveEvents which must be used for adding events to the end of the live
timeline, and addEventsToTimeline which should be used for pagination (either
back-pagination of the live timeline, or pagination of an old timeline).
2. Add some sanity checks for the live timeline. Today we have seen problems
where somehow the live timeline had gained a forward pagination token, or the
live timeline had got joined to another timeline, leading to much confusion -
and I would like to notice these sooner.
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.
