UserIdentity | Pitfalls with pin() on User, that is triggering a full IdentityChanges and can overwrite changes

(This will happen rarely, but when it does happen, it means that we are unable to communicate with someone at all, with no explanation.)

Scenario: A caller keeps a UserIdentity (I) in memory for some time; meanwhile a keys_query response updates the identity to (I') with new cross-signing keys.

A call to pin on the old identity will trigger an IdentityChange that would wrongly revert the cross-signing keys from I' to I.

=> If we expose the PIN API we need to make it resistant to that.

Consequences: a new identity update will be lost, meaning we will block sending and decrypting messages to/from a user with the new identity (and potentially send/receive to/from an outdated identity).
Notice that the next keys_query update will fix the problem (if any).

Workaround: don't hold on to the UserIdentity object in memory as much as possible - only get it and immediately call pin(). (This is the expected behaviour of EX.)

Sketch of fix: lock the DB during a write, and check we're overwriting what we think we're overwriting.

See related/similar issue with https://github.com/matrix-org/matrix-rust-sdk/issues/4073

Start in crates/matrix-sdk/src/encryption/identities/users.rs around UserIdentity::pin and compare the behavior with issue #4073. Trace how keys_query updates and the resulting IdentityChange are persisted, then verify that pinning an older identity cannot overwrite newer cross-signing keys while still applying the pin.