Require acknowledgement to send to a verified user if their identity changed or a device is unverified

[richvdh]

In "legacy/transition" mode:

When sending to a VERIFIED user with insecure devices, currently

• Currently on Web, we display a red shield on the room and user, but we do send the message.
• Currently on Element X, we fail to send and show a useful warning and a "Send anyway" button.

When sending to a user with VERIFICATION VIOLATION:

• Currently on Web, we display a red shield on the room and user, but we do send the message.
• Currently on Element X, we fail to send and show a useful warning and a "Withdraw verification and send" button.

So all of these cases are "okish" and "soon" we will move to "ignore insecure devices" mode.

In "ignore insecure devices" mode

When sending to a VERIFIED user with insecure devices, currently

• Currently on Web, we show red shields, and we silently do not send. (TODO: no need for shields any more, but we don't care much right now - no harm done.)
• Currently on Element X, we don't show shields and we silently do not send.

When sending to a user with VERIFICATION VIOLATION:

• Currently on both, we fail to send with a useless error and Retry button that won't work*

TODO: block the composer #2492

[richvdh]

Possibly matrix-org/matrix-rust-sdk#3662 does most of the groundwork for this but we need to actually wire it up in web and make sure it works

[andybalaam]

Moving to unprioritised backlog because once element-hq/element-meta#2492 is done, this will be very rare (for identity changes), and it is not a security problem - just a misleading error message when the message fails to send.

Note: ideally, instead of showing an error message, we would pick up the draft message and display it in the composer, with the warning banner already visible.

[andybalaam]

Based on discussion in Design Hour 2024-10-07 we re-wrote the top description and decided there is nothing to do.