These two commit should ideally be one, but I inadvertently pushed to
remote too early.

Includes some refactoring:

- Don't send an `active` chat state notification when entering a MUC
  I can't think of a good reason why this might be necessary or desired.
- Move `setChatState` form the view to the model
- Remove unused method `handleChatStateNotification`
- Don't store `role` and `affiliation` for the current user on the
  ChatRoom object, but instead on the ChatRoomOccupant object representing
  the user.

Also update to newer strophe.js version which contains a bugfix.

Otherwise when `removeNonMembers` gets called as we reconnect, we get a
long list of erroneous leave notifications.

This change reverts the significant part of 1dfdb36d

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.

* Create bug report template
* Create feature request template

So that the models get removed from the browser cache.
Otherwise they get re-fetched when we reconnect.

In some cases, it might be desirable to clear cached chat messages once you've
reconnected to the XMPP server.

For example, if you want to prevent the chat history from getting too long or
if you want to avoid gaps in the chat history (for example due to MAM not
returning all messages since the last cached message).

If you're using OMEMO, then you probably don't want to set this setting to
``true``. OMEMO messages can be decrypted only once, so if they then
subsequently get cleared, you won't get the plaintext back.

and use promises to indicate when an occupant or contact has been set

This is done to avoid unnecessary repaints and reflows (caused when a
message has already rendered and then an occupant is created and
attached to that message, cauring a re-render).

Related to #1266

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