Previously, we would not send unread count INCREASES to the client,
as we would expect the actual event update to wake up the client conn.
This was great because it meant the event+unread count arrived atomically
on the client. This was implemented as "parse unread counts first, then events".
However, this introduced a bug when there were >1 user in the same room. In this
scenario, one poller may get the event first, which would go through to the client.
The subsequent unread count update would then be dropped and not sent to the client.
This would just be an unfortunate UI bug if it weren't for sorting by_notification_count
and sorting by_notification_level. Both of these sort operations use the unread counts
to determine room list ordering. This list would be updated on the server, but no
list operation would be sent to the client, causing the room lists to de-sync, and
resulting in incorrect DELETE/INSERT ops. This would manifest as duplicate rooms
on the room list.
In the process of fixing this, also fix a bug where typing notifications would not
always be sent to the client - it would only do so when piggybacked due to incorrect
type switches.
Also fix another bug which prevented receipts from always being sent to the client.
This was caused by the extensions handler not checking if the receipt extension had
data to determine if it should return. This the interacted with an as-yet unfixed bug
which cleared the extension on subequent updates, causing the receipt to be lost entirely.
A fix for this will be inbound soon.
If a room moved from one window range to another window range, and the
index of the destination was the leading edge of a different window,
this would trip up the code into thinking it was a no-op move and hence
not issue a DELETE/INSERT for the 2nd window, even though it was in fact
needed. For example:
```
w1 w2
[0,1,2] 3,4,5 [6,7,8]
Move 1 to 6 turns the list into:
[0,2,3] 4,5,6 [1,7,8]
which should be the operations:
DELETE 1, INSERT 2 (val=3)
DELETE 6, INSERT 6 (val=1)
but because DELETE/INSERT both have the same index value, and the target
room is the updated room, we thought this was the same as when you have:
[0,1,2] 3,4,5
Move 0 to 0
which should no-op.
```
Fixed by ensuring that we also check that there is only 1 move operation.
If there are >1 move operations then we are moving between lists and should
include the DELETE/INSERT operation with the same index. This could manifest
itself in updated rooms spontaneously disappearing and/or neighbouring rooms
being duplicated.
- Randomly move elements 10,000 times in a sliding window.
- Fixed a bug as a result which would cause the algorithm to
fail to issue a DELETE/INSERT when the room was _inserted_
to the very end of the window range, due to it misfiring
with the logic to not issue operations for no-op moves.
Previously we wouldn't send deletions for this, even though they shift
all elements to the left. Add a battery of unit tests for the list delta
algorithm, and standardise on the practice of issuing a DELETE prior to
an INSERT for newly inserted rooms, regardless of where in the window
they appear. Previously, we may skip the DELETE at the end of the list,
which was just inconsistent of us.
