Implement a UI to expose a JS-SDK API for cancelling and resending
a room key request for an event.
This is useful in scenarios where the user has dismissed the request
on their other devices and would like to send the restart the
verification dance manually.
Depends on JS-SDK PR https://github.com/matrix-org/matrix-js-sdk/pull/624
E.g. "Bob added a Acme widget", "Susan removed a Giraffe widget"
The name is calculated by taking the `name` in the event content, falling back on the `type`, falling back on the previous content `type`. This is then capitalised.
Previously, we were special-casing outgoing messages such that they were shown
as encrypted even when encryption had failed for some reason.
There's no need for this: outgoing messages have a working isEncrypted() method
which we can use to show whether the event has been encrypted yet. Arguably we
could do better than an open padlock for events in the 'encrypting' send state,
but I'm not really sure what.
the js-sdk is making some of its APIs asynchronous, and adding an `initCrypto`
method which you have to call.
Particular methods we need to worry about are:
* `getStoredDevice`
* `getStoredDevicesForUser`
* `getEventSenderDeviceInfo`
* `isEventSenderVerified`
Fix for https://github.com/vector-im/riot-web/issues/4224
Due to the way `MatrixChat` does a state update when the `view_room` dispatch fires and a second update when `RoomViewStore` sends an update, the current event ID and room ID were becoming out of sync. The solution devised was to have the event ID managed by the `RoomViewStore` itself and do any defaulting there (for when we revisit a room that we saved scroll state for previously).
This required a few changes:
- The addition of `update_scroll_state` in `RoomViewStore` allows the `RoomView` to save scroll state for a room before swapping to another one. Previously the caching of scroll state was done in `RoomView`.
- The `view_room` dispatch now accepts an `event_id`, which dictates which event is supposed to be scrolled to in the `MessagePanel` when a new room is viewed. It also accepts `event_offset`, but currently, this isn't passed in by a dispatch in the app, but it is clobbered when loading the default position when an `event_id` isn't specified. Finally, `highlighted` was added to distinguish whether the initial event being scrolled to is also highlighted. This flag is also used by `viewRoom` in `MatrixChat` in order to decide whether to `notifyNewScreen` with the specified `event_id`.
Every file has now been manually vetted by me. Due to the extent of
the changes, I've been unable to test all scenarios to make sure this
all works. :(
