Make selector more general because Ejabberd returns `error[type="modify"]` instead of `error[type="cancel"]`.

to avoid unnecessarily destroying and then recreating ChatRoomOccupant
instances for room members.

Also ensures that we don't trigger `messageAdded` for a destroyed
message.

and re-enter if necessary.

This solves the problem where we "clone" a tab (e.g. middle-click) and
then restore a MUC from cache which we haven't actually entered (given
that the new tab represents a new device and session).

Also... add `await` in a test to try and fix Travis flakiness

So that the resource is passed along when we manually bind.

Related to bd81b897

We then use this flag to determine whether we should use the values from
sessionStorage.

This appears to fix the problem I originally tried to fix in 607d7986.

When "cloning" a tab (e.g. via middle-click), the `active` flag will be
set and we'll create a new empty user session, otherwise it'll be false
and we can re-use the user session.

This reverts commit 607d7986.

Unfortunately this doesn't solve the issue because we have a
chicken-and-egg problem due to not knowing the resource beforehand.

So what happens after this change is that we never resume XEP-0198
sessions but instead always start a new one.

Results in a 4x speedup

that they are in response to a change and not meant as an API.

Avatar didn't update a second time due to `canvas` element being expected

Otherwise we run into a bug where two tabs with Converse.js share the
same XEP-0198 SM-ID, causing both to go into a reconnection-loop as
the XMPP server switches XEP-0198 sessions between them.

This bug is due to a distinction in how sessionStorage behaves when you
open the existing site in a new tab (e.g. middle-click or
`target="_blank"), as opposed to creating a new tab
and then opening the site in that tab.

In the latter case, the newly created sessionStorage object is empty.
In the former, the contents of sessionStorage of the current page is
copied over to the new page!

otherwise a new cache entry gets created, causing multiple messages to
be restored from cache later on.

Distinguish between getting an existing entity and
creating a new one.

When creating a new one, ensure that we don't fetch from the cache.

New API method for creating a disco entity.

Only fetch messages after we have the latest room features
Otherwise we run into race conditions where MAM messages are fetched
before we know whether (updated) the room supports MAM or not.

I'm not sure how much this is an issue outside of tests, where we might
run into race conditions arising to the fact that we don't always
respond to every IQ stanza

"- Properly handle message correction being received before the corrected message"
was there twice

- Fixes #1575. Height not properly set on MUC invitation list
- Add new configuration setting: `muc_mention_autocomplete_min_chars`
- Bugfix. `min_chars` setting for MUC mentions wasn't having an effect