Disable room key requests

[richvdh]

m.room_key_request messages are a huge source of to-device messages, and the value they bring is questionable. They also make it harder to track down and fix underlying bugs in the crypto implementation, by making symptoms disappear.

Apparently the mobile Element-X clients do not send room key requests at all, and the world keeps turning.

@ara4n says:

(i really really think we should just disable them, in order to avoid clouding bugs like this)

Disabling them would fix various issues like https://github.com/vector-im/element-web/issues/26313, #19488, matrix-org/matrix-spec#1659.

Given we have key backup as a more reliable mechanism for gossiping keys between devices, why exactly do we still have room_key_request?

(This is proposed for Element-R, though presumably if it's good enough for ER we could do the same on legacy crypto?)

[dkasak]

Presumably one edge case is people who deliberately turn off their key backup.

It should also be noted that key forwards (that is, trusted key forwards, the only kind remaining today) are authenticated whereas keys retrieved from today's broken backup implementation are not. This means all messages decrypted from keys obtained from the current backup will receive ugly grey shields.

[richvdh]

We discussed this with @pmaier1 today, and we agreed to try disabling outgoing room-key requests for now, at least.

[pmaier1]

Thanks! As we want to maintain focus and improve performance, we drop this for now. We don't want to cover up root causes of UTDs with gossiping. We for now rely on backup if the user wants to have message history on new devices. We might want to re-evaluate this decision later but this is it for now.