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.
- New plugin `converse-smacks`
- New config option `enable_smacks`
- Rename session cache id from `converse.bosh-session` to `converse.session`
- Refactor logout and login as consistently used api methods
- Refactor session cache to store per JID
Fixes#316
- Combine all test init functions into `initConverse`
- Use `async` functions in more tests
- Replace `var` with `let` and `const` in more tests
- New utils method `toStanza` which converts a string to a Node
When receiving a PreKeySignalMessage, then a prekey has been chosen and
should now be removed from the list of available prekeys in the bundle,
so that a different device doesn't choose it as well.
AFAICT, libsignal removes the prekey, so it's then up to us to
regenerate it and republish our bundle.
updates #497
and if so, generate a new one.
To do so we have to change the order of events.
1. first we fetch our device list
2. then we generate our bundle info (if necessary)
3. then we update our device list (if necessary)
4. then we publish our bundle
updates #497
