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.
This removes a massive performance issue since getting sessions is part
of every message send cycle.
Namely every time we check that all our devices inside a certain room
have established 1 to 1 Olm sessions we load the account from the store.
This means we go through an account unpickling phase which contains AES
decryption every time we load sessions.
Cache instead the account info that we're going to attach to sessions
when we initially save or load the account.
