Threads: Implement the new participation model API

[manuroe]

SDK companion issue of [Prep] Threads: Design a participation model API in Matrix for EX.

---

• Add MSC4306 endpoints in Ruma
  • client-api: implement MSC4306 endpoints ruma/ruma#2169
• Add MSC4306 endpoint requests in the SDK, and expose them at the FFI layer
  • feat(sdk): add support for thread subscription endpoints (MSC4306) #5439
• Store subscription state in persistent storage
  • feat: store the thread subscription status in the database #5455
• Add support for the new push rules
  • refactor(threads): add support for MSC4306 latest changes and push rules #5483
• Automatically subscribe under the thread participation model
  • if the client's user sent an event in the thread (including the thread's root), send a manual subscription
  • if the client's been mentioned in the thread, send an automatic subscription
• Add the new postcontent section to the push rules, and update the predefined thread subs rules from MSC4306
  • common: add support for MSC4306's postcontent push rules section ruma/ruma#2193
  • update SDK after the Ruma PR has been merged
• Receive new thread subscriptions via sliding sync (MSC4308)
  • Rejigger stored subscription data format, so as to store the bumpstamp in there
    • feat(threads): store the "bump_stamps" in the thread subscriptions #5589
  • Store the (pos, prev_batch) pairs into the DB
  • Automatically catch up all subscriptions in the background (MSC4308)
  • Make Room::load_or_fetch_thread_subscription() well, actually load the subscriptions from the store.
• Add support for the new endpoint for catching up subscriptions (MSC4308)
  • client-api: add support for msc4308 accompanying endpoint ruma/ruma#2194
  • client-api: add ctors to ThreadSubscription and ThreadUnsubscription ruma/ruma#2200
  • feat(threads): implement msc4308 companion endpoint #5590

[bnjbvr]

Some small status update. I'll need to rejigger the data format used to save the subscriptions in the DB; after all, we need to save the bumpstamp and the status (unsubscribed/subscribed), so as to be able to order subscriptions against unsubscriptions (and conversely).

Once that's done: I think that MSC4308 also implicitly requires that we save the (pos, next_batch) token pairs in the database, to be able to continue back-paginating thread subscriptions from the last place we did (since we can get interrupted at any point in the process, and worst case we'll be interrupted multiple times after multiple gaps — so we can have a chain of these token pairs in DB).