UserIdentity | Pitfalls with pin() on User, that is triggering a full IdentityChanges and can overwrite changes
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.)
See related/similar issue with https://github.com/matrix-org/matrix-rust-sdk/issues/4073