[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

• Introduce dirtiness inside CrossProcessLock:
  • feat(common): Add cross-process lock dirtying #5672
  • refactor(common): Provide a unified, solid API between try_lock_once and spin_lock on CrossProcessLock #5837
• Update MediaStore to use the new dirtiness
  • feat(base): Explicitly handle the CrossProcessLockKind::Dirty case in MediaStore #5855
• Update OAuth to use the new dirtiness
• Update EventCacheStore to use the new dirtiness
  • feat(base,sdk): Support for dirty cross-process lock in the EventCache #5856
• Update CryptoStore to use the new dirtiness
• Remove the previous “cache invalidation” mechanism in the CryptoStore

[Hywan]

Also see this comment #4285 (comment)