Depend on latest backbone.browserStorage which has support for IndexedDB
via localforage.
Storage operations are now asynchronous and transactional.
Bugs fixed (mostly by waiting for operations to complete):
* Rooms are now fetched asynchronously, so wait before triggering `show`
or when closing.
* Make sure chat create/update transactions complete before firing events
* Make sure chats and messages have been fetched before creating new ones.
* When doing a `fetch` with `wait: false` on a collection and then
creating a model in that collection, then once the read
operation finishes (after creating the model), the collection is emptied again.
* Patch and wait when saving.
Otherwise we have previously set attributes overriding later ones.
* Make sure api.roomviews.close returns a promise
Test fixes:
* Chats are now asynchronously returned, so we need to use `await`
* Wait for the storage transaction to complete when creating and updating messages
* Wait for all chatboxes to close
Otherwise we get sessionStorage inconsistencies due to the async nature of localforage.
* Wait for room views to close in spec/chatroom.js
In the process, remove the `closeAllChatBoxes` override in
converse-controlbox by letting the `close` method decide whether it
should be closed or not.
This change reverts the significant part of 1dfdb36d20
I can't say that I understand why libsignal throws `Error: Invalid signature`
when you try to build a session for your own (sending) device, but given that
messages can only be decrypted once, I guess it isn't really necessary
to encrypt for your own device, since you already have the plaintext.
In addition I've added some error handling so that we can recover
gracefully when session building fails for a subset of devices.
Instead of deleting devices that are not returned in the device list,
set an `active` flag, so that we don't remove the trust setting.
Set deactivated devices to `active` when a receive an OMEMO message from
it.
Also, set omemo_supported to true when we've succesfully decrypted a
message.
Until now, we've only been explicitly documenting the `_converse.api`
namespace and only considered the methods under it as forming the API
contract (which determines how we do semver releases).
It appears as if we've reached a point where trying to keep everything
under the `_converse.api` namespace no longer makes sense. Certain
methods are applicable to particular models and trying to shoehorn them
into the `_converse.api` namespace seems clunky and non-intuitive.
I've therefore decided to slightly refactor `sendMessage` to let it take
two simple parameters and to document it with JSDoc so that it's
presented as an API method, albeit only available on a chat model.
updates #1496
updates #1504
