Previously, these methods returned `SyncRoomEvent`s instead, even though
the decrypted events are required to contain a room_id field (in order
for the server to not to be able to change these). As a side effect,
glue code which adds a room_id to the `SyncRoomEvent` to convert it to a
`RoomEvent` is be removed in some places.
When a `SyncRoomEvent` is required (such as in code handling sync
responses), the `From` implementation of `SyncRoomEvent` can be used.
According to the guide for implementing verification started from
a verification request, both parties should (or at least allowed to)
send a start request when the verification is ready. However, only the
start request from the party with lexicographically smaller user id (or
device id, for device verification, and thus equal user id) is supposed
to be accepted, and the other one ignored.
Previously, when a sas-workflow was started by the other party (e.g.
from a verification request), but the own start request was answered with
an "accept" this accept would be ignored. However, this is incorrect
since the official guide on implementing verification actually states
that both parties are expected to send start-requests, where of those
only one request is actually accepted (depending on user id and possibly
the device id).
Without this change, a batch with a message that cannot be deserialized
(for whatever reason) means that the batch cannot be processed at all by
the caller. Now, those messages are returned unchanged in the batch so
that the caller can handle them.
Due to additional error possibilities and encryption info for messages,
the return type of the method was changed accordingly and a wrapper
struct `Messages` was introduced.
Clients might want to retry decryption after they import room keys, for
this to be efficient they'll need to know which room keys got imported.
This patch extends the return value of the room key import result to
include the map of room keys that got imported.
Some clients might have skipped the serialization of an empty
sender_claimed_keys and the forwarding_curve25519_key_chain, while these
fields are required there's really no upside in requiring them if they
are empty.
So create defaults if they are missing.
Kévin Commaille