Fixes https://github.com/vector-im/riot-web/issues/14411
The act of setting/changing the algorithm was causing the update function to be marked, meaning we wouldn't trigger an update until something else happened later. To get around this, and still support internal functions spamming calls without multiple updates, we simply move the guts to an internalized function and make the public interface do a trigger.
For https://github.com/vector-im/riot-web/issues/14035
**This option is not recommended as it completely obliterates all chances of being able to support someone with a broken room list. It is intended for specific testing scenarios only.**
The room list does a hefty amount of work, so instead of blocking the event loop with a `/sync` request and a bunch of room updates (as we can get multiple per sync) we can instead run it over several smaller tasks. The smaller tasks help the event loop do other things between our tasks, ensuring we don't inadvertently block the UI from rendering too slowly.
On my account and machine, this cuts the time to render in half (~30ms, down from ~60ms) .
The core of this is in the MarkedExecution class, with the remainder of the commit ensuring that the right marks and triggers are in place to do the firing.
Because everything is async/await and run through the RoomListStore, we don't have to worry about self-fed updates in the algorithm classes. This also means we have to trigger pretty much all the time.
Changes to tag ordering / list sorting get hit through two paths, so we mark before we do a bulk update and otherwise assume the call is coming in from outside.
This is more general maintenance than performance as the RoomList doesn't need to be generating layouts for the sublists, and it certainly doesn't need to be creating a bunch of extra ones.
The sublists are perfectly capable of getting their own layout instance and using it, and we are perfectly able to limit the number of these things we create through the session's lifespan.
We don't need the fake clock anymore, but we do have to wait for async actions to complete before moving forward.
This also exposes a number of functions for the store to be puppetted with.
Fixes https://github.com/vector-im/riot-web/issues/14372
We read/use the options in multiple places, and those places were not in sync. Now when algorithms change and on initial load, both will come to the same conclusions about how to order & sort the rooms.
We have to do a bit of a dance to return the sticky room to the list so we can remove it, if needed, and ensure that we generally swap the rooms out of the list.
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.
