Update message sender trust status when user's verification state improves

[andybalaam]

Follow up to #3544

If a user is in verification violation and then they become verified OR we withdraw verification (making them unverified), update their sessions so messages from them have the updated status.

Current situation

• On Web, if you verify after being in verification violation, your new messages have no shield. (Also old messages, at least some of them.)

• On Element X, if you verify after being in verification violation, your new messages have no shield. (Your old ones keep the shield that they gained when you were in verification violation.)

So in both cases, new messages are displayed correctly. This story is to fix old messages.

This may already be fine on Web, in which case this story is just to fix Element X.

Implementation

• Allow querying inbound group sessions by master key (remember to populate even for Unverified sessions)

  • Add an indexed column on master key
  • Populate it
  • Allow querying based on it

• Update SenderData when an identity becomes verified or verification is withdrawn.

  • When /keys/query shows someone became verified recalculate all sessions for that master key with Unverified or PreviouslyVerified state
  • When we withdraw verification recalculate all sessions for that master key with PreviouslyVerified state

• Notify the UI code that the message needs updating (maybe by re-running decryption, or just by updating the shields)

[andybalaam]

Note for prioritisation: the critical thing here is to make sure future messages do not have shields after we have withdrawn or re-done verification. Updating older messages is a nice to have.

So maybe we can just do this during decryption instead of re-querying for old sessions.

[richvdh]

Note that we need to implement this even for messages that were sent by devices that have since been deleted. We have all the necessary information in the SenderData, but I think it would be easy to mess this up. (Specifically: if you jump straight back into the top of the SenderDataFinder algorithm as the current code does, you'll get UnknownDevice out the end.)

[BillCarsonFr]

Other related scenario were updating a message trust status would be helpfull:

• Alice and Bob are talking in a room, Bob device is secure (cross signed by it's identity)
• Put alice in offline mode (close tab on web)
• Logout bob, then log-in again and reset the identity (as if you've forgot recovery)
• Bob sends a new message

=> Open alice session again:

Alice receives the new room_key for the new message. The embedded device_keys are not signed with the identity we have for Bob (it is signed by a not yet known identity)
=> So the device is flagged insecure. If exclude insecure device is on, it will be in UTD

In the same sync cycle Bob is marked as dirty, so the a new keys/query is make (and that's only now that we learn about the new identity that signs the new device)

Future messages will be fine though.

Another thing to note is that other sessions that were online will get the identity update before the message is sent, so this same message will be decrypted fine on other sessions