* refactor: sliding sync: swap to lists-as-keys
Update the request/response API shape to match the latest
MSC3575 version, which converts `lists` from being an array
of list objects to being a map of list objects.
* Linting
* prettier
* add extra setListRanges test
* Default to right type
* refactor: sliding sync: swap to lists-as-keys
Update the request/response API shape to match the latest
MSC3575 version, which converts `lists` from being an array
of list objects to being a map of list objects.
* Linting
* prettier
* add extra setListRanges test
* Default to right type
* `matrix-client-crypto.spec.ts` only tested a very specific bit of crypto (olm
encryption). It goes back to the very early days, before Megolm was invented.
I've renamed it to `olm-encryption-spec.ts`.
* `megolm-integ.spec.ts` is more of a general crypto test; it was just called
`megolm` to distinguish it from the Olm tests above. Renamed to
`crypto.spec.ts`.
These are all called by the react-sdk when showing an encrypted event:
* `getEventEncryptionInfo`
* `checkUserTrust`
* `checkDeviceTrust`
I don't particularly want to keep this API, but as a rapid means to an end,
let's stub them for now.
This test seemed to be testing the behaviour of decrypting redacted events, but
that seems... strange. A redaction event cannot be encrypted (at least, there
is no spec for it), and it should be impossible to decrypt a (correctly)
redacted event, because such an event will lack a `ciphertext` property.
This test is just sticking a "redacted_because" property into a regular event,
which is a bit of a nonsense.
Adds a log line whenever we save a session and also adds an event
that's fired whenever we get a to-device event we can't decrypt
(hopefully the comment explains all).
The megolm tests were making a few assumptions which they really shouldn't; in
particular:
* They were creating mock events with event_ids not starting `$`, and lacking
`sender`, `origin_server_ts` and `unsigned` properties
* They were not including the (now) required `keys.ed25519` property inside
the ciphertext of an olm message.
These work ok currently, but they aren't really correct, and they cause
problems when testing the new rust implementation.
David Baker