Split out the sliding sync loop into two loops

[poljar]

As described in #1928, it would be beneficial if our sync setup involves two loops which don't block each other.

One loop would be for user facing data, the other one for to-device traffic.

The public API should mostly hide the fact that this is happening. We can likely remove the enabling/disabling of the to-device extension from the public API wholesale.

[bnjbvr]

Some notes from my current implementation for this:

• it might be required to implement Change the store traits so they expose a transactional API #2000 so we can avoid "one task does partial writes while another task does read" database situations. This could happen because the main loop and the to-device loop would run concurrently.
• it's not only to-devices, but also the e2ee extension that must run in the second loop.

I've got a naive implementation that mostly reproduces the logic of running a sliding-sync request, that could be refactored. Since these changes are non trivial and would move a lot of code, I think it'd make sense to sync about it before I start doing it:

• one goal is for the FFI object and public API to not change, to start with.
• extract the fields from SlidingSync that are responsible of handling a SS request into a SlidingSyncLoop helper: position marker tracking, reset counter
• extract into "request components" the bits that are specific to each sub-request:
  • for the "main" sync loop, that would be the list of lists (named lists) + sticky parameters
  • for the "to-device" sync loop, that would be another set of sticky parameters
• now the main loop is a SlidingSyncLoop that has the "main" request components, and another SlidingSyncLoop that has the "to-device" request components
  • future notification process will use a SlidingSyncLoop that enables the to-device component + what it needs for responding to call notifications

Does it make sense @Hywan?

[bnjbvr]

Reporting from the quick chat we've had with @Hywan: let's keep SlidingSync as is, but make it so that it sends fewer things by requests according to the "role" of the sliding sync, and have an higher-level API with multiple sliding sync for the main app (or hide that in the FFI layer).