Use different m.room_key.withheld codes for "user not verified" from "device not verified"

[richvdh]

It is possible to configure clients not to share message keys with unverified devices, including devices belonging to unverified users.

For example, Element-Web exposes this option (at both the global and room level):

When this happens, an m.room_key.withheld message is sent to the recipient, using a withheld code m.unverified.

The problem with this is that the recipient of such a message cannot easily tell whether the key was withheld because their device is not verified, or because there has been no cross-user verification.

We think we should introduce more explicit "withheld" codes to distinguish between the two cases.

Note that rolling this out will take some time: we'll first have to update as many clients as we can to understand the new codes; only after some time will we be able to start sending the new codes.

[richvdh]

Some more thoughts:

Once we update Element Web to force verification on login/load (element-hq/element-web#28464), the only plausible reason to receive an m.unverified will be because the users aren't verified.

So maybe we could just assume that if you receive an m.unverified, it's because the sender is in paranoid mode and hasn't verified our user, and we don't really need separate codes?

[I don't really like that, because (a) there is the chance that the sender had an out-of-date copy of our device keys so thinks that the device is unverified; (b) it just feels way more robust for the sender to be more explicit about the reason for not sending keys]