[meta] _Dirty_ cross-process locks

[Hywan]

During our work on the event cache store, we have worked on improving the event cache store to introduce lock and lock_unchecked with the notion of dirtiness (previously: poison). This issue aims at extending this notion to all cross-process locks.

Imagine the following scenario:

• holder A takes the lock for the first time: lock is clean,
• holder A takes the lock for the second time: lock is still clean,
• holder B takes the lock for the first time, it's stolen from holder A: lock is still clean
• holder A takes the lock for the third time, it's stolen from holder B: lock is dirty.

When the lock is obtained, it is either clean or dirty. When dirty it indicates that the internal in-memory state should be invalidated and refreshed.

Tasks

• [x] Introduce dirtiness inside CrossProcessLock:
  • [x] https://github.com/matrix-org/matrix-rust-sdk/pull/5672
  • [x] https://github.com/matrix-org/matrix-rust-sdk/pull/5837
• [x] Update MediaStore to use the new dirtiness
  • [x] https://github.com/matrix-org/matrix-rust-sdk/pull/5855
• [ ] Update OAuth to use the new dirtiness
• [x] Update EventCacheStore to use the new dirtiness
  • [x] https://github.com/matrix-org/matrix-rust-sdk/pull/5856
• [ ] Update CryptoStore to use the new dirtiness
• [ ] Remove the previous “cache invalidation” mechanism in the CryptoStore

[Hywan]

Also see this comment https://github.com/matrix-org/matrix-rust-sdk/pull/4285#issuecomment-2488655073