feat: Migrate from Sliding Sync to Simplified Sliding Sync

[Hywan]

We want to support the Simplified MSC3575 (temporary name).

This PR should be reviewed patch-by-patch. It's not super complex, but you need to understand the approach:

1. Create a matrix_sdk_base::sliding_sync::http module, which provides all the HTTP types for MSC3575,
2. Migrate the entire codebase to use this module instead of ruma: it's just type aliases at this point, but it's important for the next steps; tl;dr: s/ruma::…::sync::v4/matrix_sdk_base::sliding_sync::http:ss,
3. This http module then provides HTTP types for Simplified MSC3575 (!) + conversions from MSC3575 to Simplified MSC3575, and exposes Simplfied MSC3575 as the default types,
4. Switch the entire codebase to use Simplified MSC3575; tl;dr: s/http:ss/http + remove features from MSC3575 that are no longer used in Simplified MSC3575 (like sort, bump_event_types, unsubscribe_rooms) or rename some features (like timestamp to bump_stamp),
5. Finally, since now the entire codebase uses Simplified MSC3575, we need a mechanism to convert the Simplified MSC3575 Request into a MSC3575 Request and the opposite for the Response. It's done with a experimental-not-simplified-sliding-sync flag.
6. … Bonus: experimental-not-simplified-sliding-sync turned to be difficult to use esp. when testing the whole project with --workspace. Instead, we went a bit further and replace this compiler feature flag by a runtime configuration on the Client with Client::is_simplified_sliding_sync_enabled. That way we can decide at runtime if we want Simplified MSC3575 or the ol' MSC3575.

Why this approach?

• The day we fully sunset MSC3575, we simply remove Client::is_simplified_sliding_sync_enabled
• Since we can decide at runtime to enable Simplified or regular MSC3575, it's easier for the apps (like Element X, Fractal etc.) to play with it.

---

• Address [meta] SSS & PPS #3647

[bnjbvr]

Please request another round of review when the PR is stable and there are no new commits while I'm reviewing :)

[codecov]

Codecov Report

Attention: Patch coverage is 81.25000% with 15 lines in your changes missing coverage. Please review.

Project coverage is 84.01%. Comparing base (b79fdef) to head (07b2004).

Files	Patch %	Lines
crates/matrix-sdk/src/sliding_sync/builder.rs	47.05%	9 Missing ⚠️
crates/matrix-sdk/src/sliding_sync/mod.rs	80.00%	4 Missing ⚠️
crates/matrix-sdk-base/src/sliding_sync/mod.rs	85.71%	1 Missing ⚠️
...s/matrix-sdk-ui/src/room_list_service/room_list.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3676      +/-   ##
==========================================
- Coverage   84.37%   84.01%   -0.37%     
==========================================
  Files         260      260              
  Lines       26783    26700      -83     
==========================================
- Hits        22598    22431     -167     
- Misses       4185     4269      +84     

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

[bnjbvr]

Cool to see SSS coming to life, I appreciate the amount of work on this and done in Ruma under the hood 👏

There are a few strong no-noes in that PR that make it impossible to land in the current shape.

9961db5 should be in Ruma, not in our code. Too many code smells, likely too hard to maintain in the long term.

a9f22d1 was super hard to review. From a glance, it would have seemed much much simpler to review if it were split into smaller commits:

• get rid of the delta token (to fuse with the latest commit)
• get rid of the unsubscribe mechanism (why can we do that? we still have to support SS as it is right now)
• remove the ::ss namespacing in most of the code
• rename the recency_timestamp to recency_stamp and associated code

I understand that all these changes must come before the actual migration from SS to SSS, but it would've been much much simpler to review if those changes were smaller (usually when i see a commit titled "rename X to Y", if i agree with the renaming i'll skim the code real-quick, and that takes me much less time, than trying to disentangle many changes that live in the same commit).

Pretty sure there's a big regression for SS, since we get rid of the unsubscribe() mechanism a bit too early in the patch set.

Also: do we need a8a1315? I thought we said that having static configuration was sufficient…

[poljar]

I think that this looks fine, the PR is a bit chunky but most of it are type swaps.

I left some small nits, feel free to merge once addressed. Bonus points if you get the history cleaned up as well.

damir reviewed it