Done messages are supposed to indicate that the verification was
successful and _can be_ finalized. The correct time to send Done events
is after the user has confirmed the verification (after checking the
emoji or similar) and after receiving and checking a mac from the other
party (whatever happens later). Waiting for the other side to send Done
before sending it ourselves does not make sense.
Being in MacReceived state means that the other party has confirmed that
emojis/numbers match and the sent mac messages has been successfully
checked. When now confirming ourselves this means that the verification
was successful and thus the Done message can be sent to the other party.
When during verification we are the first party to complete the
verification workflow and then receive a (correct) MAC from the other
party, we need to send out the Done message even if we have not received
the Done message from the other party ourselves and are thus still
"WaitingForDone".
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.
Damir Jelić