Usually only room keys and forwarded room keys are sent as encrypted
to-device events, those are specially handled to avoid accepting room
keys coming in unencrypted.
Some clients might send out other events encrypted which might lower
metadata leakage and the spec doesn't disallow it.
This patch handles decrypted events the same way as non-encrypted ones,
we're still special casing the decryption handling to avoid decryption
loops/bombs (i.e. events that are encrypted multiple times).
Sending out automatic key requests is a bit spammy for new logins,
they'll likely have many undecryptable events upon an initial sync.
It's unlikely that anyone will respond to such a key request since keys are
shared only with verified devices between devices of the same user or if
the key owner knows that the device should have received the key.
Upon initial sync it's unlikely that we have been verified and the key
owner likely did not intend to send us the key since we just created the
new device.
This improves two things, use the correct outbound session to check if
the session should be shared.
Check first if the session has been shared if there isn't a session or
it hasn't been shared check if the request is comming from our own user.
Use MxcUri instead of String for media URLs.
Fix wrong MXC URIs in tests.
Remove method parse_mxc no longer useful.
Apply new non-exhaustive types: CrossSigningKey, OneTimeKey and SignedKey.
Apply endpoint name change: send_state_event_for_key to send_state_event
We were merging the to-device messages using the extend() method while
our data has the shape of BTreeMap<UserId, BTreeMap<_, _>>, extending
such a map would mean that the inner BTreeMap would get dropped if both
maps contain the same UserId.
We need to extend the inner maps, those are guaranteed to contain unique
device ids.
Intersect the allowed methods passed from the user with the methods
supported by the other party. If the user added new methods to the
request, the remote party would cancel the verification.