feat(threads): automatically subscribe a user to a thread under the semantics of MSC4306

[bnjbvr]

Based on #5455 + #5461, this implements automatic subscription to threads which explicitly mention the current user (via an intentional room or user mention), and likewise sends a manual subscription to a thread when replying into it.

There's a single background task, owned by the event cache, that will listen to two input streams, and create automatic thread subscriptions based on these streams.

• one stream is the global event cache linked chunk update stream, introduced in this PR (and that could be fused in the future with the RoomEventCacheGenericUpdate stream). Based on the new events propagated in a linked chunk update, we can compute the notifications for those, and decide to subscribe to a thread, based on those.
• the other stream is the global send queue stream (thanks for adding this in another PR!). Ideally, we'd have the full event's content when it's sent, and we could only react to Sent updates. We could embed the sent event in the Sent variant, as a simplification; otherwise, we keep just a bit of state, to link the to-be-sent event (transaction id) to its thread root.

Topics to discuss:

• having the event cache own this task is a bit strange since it also listens to the send queue. We could put it in the client, but at this point, since both the send q and the event cache should be enabled at the same time, and we'd want to have the event cache stream around, I thought it was just as simple to put it in the event cache.
• as hinted above: the send q update Sent could embed the sent event, which would avoid the mapping of to-be-sent event to a thread root.

PR is a bit big, but mostly because of the tests; the core code isn't that big.

Part of #4869.

[codecov]

Codecov Report

❌ Patch coverage is 92.72727% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.59%. Comparing base (247ec1d) to head (a682a46).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
crates/matrix-sdk/src/event_cache/mod.rs	85.18%	4 Missing ⚠️
crates/matrix-sdk/src/event_cache/room/mod.rs	86.66%	0 Missing and 2 partials ⚠️
crates/matrix-sdk-common/src/serde_helpers.rs	85.71%	0 Missing and 1 partial ⚠️
crates/matrix-sdk/src/room/mod.rs	96.55%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5462      +/-   ##
==========================================
+ Coverage   88.56%   88.59%   +0.02%     
==========================================
  Files         340      340              
  Lines       93686    93780      +94     
  Branches    93686    93780      +94     
==========================================
+ Hits        82975    83082     +107     
+ Misses       6578     6565      -13     
  Partials     4133     4133              

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

[codspeed-hq]

CodSpeed Performance Report

Merging #5462 will not alter performance

_{Comparing bnjbvr/auto-sub-threads (a682a46) with main (247ec1d)}

Summary

✅ 31 untouched benchmarks

[Hywan]

Looks good. I don't understand all the details for the moment. I've left a couple of questions. Thanks for your contributions!

[Hywan]

Can you add a comment here to explain why we call subscribe_to_new_threads at this place please?

[Hywan]

Re-reading this, I don't understand why we subscribe to threads here :-].

[bnjbvr]

This is the "main" events timeline, which has threaded and non-threaded events. So when we're back-paginating, we might run into threaded for which no subscriptions have ever been computed (i.e. the threads existed before we created the subscription mechanism). In this case, we still want to be able to "catch up" and automatically subscribe the user.

[Hywan]

Why not type ThreadPushContext = Option<PushContext>? What the benefits of having a new type?

[bnjbvr]

Newtypes allow hiding the inner workings. I don't want users to pass a general ThreadPushContext to the method that determines whether we should subscribe to a thread or not, because the push context shouldn't have the thread-subscription check. So it has to be a specific flavor of PushContext to be passed in there, and I don't want the user to care about this; they can create a ThreadPushContext with the other function, and not think too much about the implementation details.

[bnjbvr]

Ready for another round of review 🥳 This also implements support for manually subscribing when an event is sent via the send queue, as per the semantics of MSC4306.

PTAL 🥳