feat: Implement cross-process lock for the EventCache

[Hywan]

This PR must be reviewed commit-by-commit.

It introduces the LockableEventCacheStore type, which wraps DynEventCacheStore, and that implements BackingStore so that it can be used inside the CrossProcessStoreLock.

It then introduces the EventCacheStoreLock type, which glue all pieces together: the CrossProcessStoreLock and the LockableEventCacheStore. It exposes a single method: lock(&'a self) -> Result<EventCacheStoreLockGuard<'a>, _>, which allows to take the lock. The guard derefs to DynEventCacheStore. The resulting API is straightforward to use according to me: client.event_cache_store().lock().await?, pretty Rust idiomatic.

Finally, the PR replaces all uses of DynEventCacheStore by EventCacheStoreLock. There is no more public DynEventCacheStore, expect via EventCacheStoreLock.

A follow-up patch must update matrix_sdk::event_cache to refresh the in-memory data of the event cache when the lock holder has changed. I believe it's nice to introduce that in another PR instead of increasing the number of patches in this one.

---

• Address [meta] EventCache storage #3280

[codecov]

Codecov Report

Attention: Patch coverage is 98.96907% with 1 line in your changes missing coverage. Please review.

Project coverage is 84.89%. Comparing base (71abbeb) to head (c2e99b3).
Report is 40 commits behind head on main.

Files with missing lines	Patch %	Lines
crates/matrix-sdk/src/client/builder/mod.rs	80.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4192      +/-   ##
==========================================
- Coverage   84.89%   84.89%   -0.01%     
==========================================
  Files         272      272              
  Lines       29142    29208      +66     
==========================================
+ Hits        24739    24795      +56     
- Misses       4403     4413      +10     

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

[bnjbvr]

Great! It's nice that we can reuse so much code for the cross-process locking 🥳

[bnjbvr]

The values provided here are scary, and should be controllable by the callers, otherwise it's not possible to distinguish a process from another. The key could be a constant used everywhere in the codebase (maybe buried into a single place, and then passed around — or buried a single time when creating an EventCacheStoreLock from an event cache store impl), but the holder's value has to be provided by the embedder.

[Hywan]

I would like to address that as a follow-up PR: I want to introduce a "process holder name" inside the client that can be used by all cross-process lock, otherwise things start to be really clumsy. What do you think?

[Hywan]

@bnjbvr and I have agreed to remove these values with a configuration in the Client. I'm already working on this as a follow-up PR.

[Hywan]

Here it is, #4224

[bnjbvr]

lgtm, thanks!