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

[BillCarsonFr]

(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 #4073