feat(ui): Add the new latest_event room list sorter, and update the recency sorter

[Hywan]

This set of patches updates the room list to sort rooms by their “latest event”. What does it mean?

• We want a room with a local latest event to be at the top of the room list,
• We want a room to have an accurate position in the room list, which means we want to rely on the latest event instead of the room recency_stamp (also known as the bump_stamp in sliding sync terminology):
  • Why was recency_stamp inaccurate? Because the server might bump a room based on certain events, so the room will bump in the room list, but the latest event won't change because the event causing the bump is not a latest event candidate. Because the latest event is used by som apps to display the room “last updated time” in the room, the user might see unordered rooms!
  • One may argue that we should keep the list of events triggering a bump on the server in-sync with the list of latest event candidates on the client side. I would happily counter-argue that it's server-dependent and client-dependent. Not all servers and not all clients want the same behaviour. The list on the server is “best-effort”. Also, it's not configurable anymore with Simplified Sliding Sync (MSC4186).
  • One may also argue that sorting by latest event's timestamp means we use the famous origin_server_rs value, which is a mistake because it can be forged by malicious servers! Yes, that's true, but:
    • There is no security risk involved here. At worst, a room is sticked at the top or the bottom of the room list, that's it.
    • We were using this value in the past and we agreed it was fine (happy to re-discuss that if needed).
    • Some homeservers can use the origin_server_ts value of the last event in the room as the value for bump_stamp. We can't control this, it's an opaque value.

All-in-all, this set of patches creates a new latest_event sorter for the room list. Then it updates the recency sorter to be “latest-event aware”. Finally, it installs the new latest_event sorter.

---

• Address [meta] Latest Event API, the missing one #4112

[codecov]

Codecov Report

❌ Patch coverage is 96.33205% with 19 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.93%. Comparing base (441b006) to head (d9db53e).
⚠️ Report is 11 commits behind head on main.

Files with missing lines	Patch %	Lines
.../room_list_service/filters/deduplicate_versions.rs	81.25%	6 Missing ⚠️
...x-sdk-ui/src/room_list_service/filters/category.rs	87.50%	2 Missing ⚠️
...rix-sdk-ui/src/room_list_service/filters/invite.rs	71.42%	2 Missing ⚠️
...rix-sdk-ui/src/room_list_service/filters/joined.rs	71.42%	2 Missing ⚠️
...k-ui/src/room_list_service/filters/low_priority.rs	66.66%	2 Missing ⚠️
...trix-sdk-ui/src/room_list_service/filters/space.rs	66.66%	2 Missing ⚠️
...rix-sdk-ui/src/room_list_service/filters/unread.rs	92.85%	2 Missing ⚠️
...-sdk-ui/src/room_list_service/filters/favourite.rs	80.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5617      +/-   ##
==========================================
+ Coverage   88.89%   88.93%   +0.04%     
==========================================
  Files         349      350       +1     
  Lines       96546    96854     +308     
  Branches    96546    96854     +308     
==========================================
+ Hits        85826    86140     +314     
+ Misses       6682     6676       -6     
  Partials     4038     4038              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

CodSpeed Performance Report

Merging #5617 will not alter performance

_{Comparing Hywan:feat-ui-latest-events-sorter (d9db53e) with main (441b006)}

Summary

✅ 49 untouched benchmarks

[poljar]

Most of it makes sense and thanks for the comprehensive test suite.

I left some questions and recommendations that I think make sense.

[poljar]

We discussed this in chat but the discussion died down, so I'll repeat here.

To avoid malicious homeservers and users manipulating our room ordering using the origin_server_ts can't we record a local timestamp whenever we create a new LatestEventValue?

[Hywan]

Yeah. I've been thinking about that.

When we receive an event via the sync, we can record the now() as the local timestamp. However, it means that all events from all rooms for a particular sync will have the same local timestamp, and thus, we can't use that to sort the rooms (because all “recorded timestamps” will be equal).

I think we have to keep origin_server_ts for the moment. We can warn it's a known limitations. It's also used to display the event's time in the timeline for example. If we can't trust this value, it's a protocol issue I suppose. I don't see how to solve that for the moment.

[poljar]

Alright, looks good.

There's still the question of using origin_server_ts exclusively for this, but as you said, this can be a separate PR.