Also extra robustness while filling a gap
ignore duplicate events from synapse instead considering them an
overlapping event with the adjacent fragment
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!
- also remove m.room.aliases support as they were wrongly implemented
and now obsolete
- don't count invited and joined members according to m.room.member
events anymore as it was also wrongly implemented
(only when prev!==new membership, but on initial sync we only get
last member event, which might have been a nick change
when doing a limited sync, and a new fragment is created,
this._lastLiveKey is updated immediately. If the transaction
would then fail, the fragmentId in this._lastLiveKey was incremented
but the fragment wasn't written to the store, so if sync is resumed
and would subsequently succeed, fragmentIds would be assigned to events
that don't have a corresponding fragment in the timelineFragment store.
This would throw errors when trying to load the timeline,
breaking the whole app.
This changes SyncWriter to only update this._lastLiveKey in
the emit phase, when the transactions has been committed already.
it only has content and *some* of the meta fields,
but we want to threat pendingevententry and evententry as one
and the same in the rest of the application, so don't give access
to entire event object.
