The `TimelinePanel` uses two timers to coordinate read marker and read receipt
updates. When the read receipt timer fires, we advance the receipt and send the
latest state of both your receipt and marker to the server. When the read marker
timer fires, we advance the marker visually, but do not send anything to the
server: we were relying on the slightly different schedule of the read receipt
to actually send the updated read marker. This means there's a time window where
it's possible to visually advance the read marker without ever sending it to the
server (if you change rooms before the receipt timer fires again).
To simplify the behaviour here and ensure we always commit the updated marker
when we move it, this change sends an update to the server at the same time as
moving the marker.
It's possible this may improve some of the behaviour reported in
https://github.com/vector-im/riot-web/issues/12338.
Updates are passed along magically to the sublist, so we don't need to listen for the room list store's response to our changes.
This just hits the functions introduced in the last commit.
This commit is a bit involved, as it factors the tag specific handling out of `/list-ordering` (and moves the `Algorithm` class one higher as a result), leaving it in the `Algorithm`. The algorithms for list ordering now only know how to handle a single tag, and this is managed by the `Algorithm` class - which is also no longer the base class for the list ordering. The list ordering algorithms now inherit from a generic `OrderingAlgorithm` base class which handles some rudimentary things.
Overall the logic hasn't changed much: the tag-specific stuff has been moved into the `Algorithm`, and the list ordering algorithms essentially just removed the iteration on tags. The `RoomListStore2` still shovels a bunch of information over to the `Algorithm`, which can lead to an awkward code flow however this commit is meant to keep the number of surfaces touched to a minimum.
The RoomListStore has also gained the ability to set per-list (tag) ordering and sorting, which is required for the new room list. The assumption that it defaults from the account-level settings is not reviewed by design, yet. This decision is deferred.
It had ~32px of overflow causing a horizontal scrollbar. Turns out the layout engine gets confused when hidden elements are at the end of a flexbox, so we just move them higher in the DOM (where they logically still make sense).
The remaining changes are all alignment and misc changes in that respect, and probably not obvious.
