Don't remove cached presences in `afterTearDown` event.
We might reconnect again and resume the session, in which case we need
that data still.

Instead, we remove cached presences when `clearSession` fires, because
then we know we're not reconnecting.

When reconnecting, we don't fetch presences from cache, we still have
them (since we no longer remove them in `afterTearDown`).

When reconnecting and not resuming, we clear the presences from cache,
since we're starting a new session.

Translated using Weblate (Chinese (Simplified))
Currently translated at 41.8% (158 of 378 strings)
Translate-URL: https://hosted.weblate.org/projects/conversejs/translations/zh_Hans/

Translated using Weblate (Russian)
Currently translated at 96.8% (366 of 378 strings)
Translate-URL: https://hosted.weblate.org/projects/conversejs/translations/ru/

Added translation using Weblate (Occitan)
Translated using Weblate (Occitan)
Currently translated at 79.9% (302 of 378 strings)
Translate-URL: https://hosted.weblate.org/projects/conversejs/translations/oc/

* Explicit forwards and backwards paging
* Include upper or lower bound when calling `RSM.prototype.next` or `RSM.prototype.previous`
* Bugfix: Don't override new RSM parameters (caused infinite recursion)

to conform to conventions

Also fix a bug in the code dermining whether an XMLElement stanza is only a chat state notification

* _.isNil
* _.noop
* _.isNull

We do that in `clearSession` and otherwise when we auto-reconnect we end
up without a roster.

to `show_chat_state_notifications`

Fixes #1548

Shadow dom: TypeError: Cannot read property 'parentElement' of null caused by MinimizedChatsToggleView

If we've fetched the roster before within this session, then we don't
have to do so again, regardless of whether versioning is supported or
not, otherwise, even if we have a cached roster, we still need to get
the latest one again.

Otherwise `converse.features` cache id contains `null` instead of the
user JID and it doesn't clear correctly.

by not logging in automatically when `auto_login` is `false` and we're
using anonymous, external or prebind authentication.

For `authentication` set to `login` the situation is much more
ambiguous, since we don't have a clear distinction between wether we're
restoring a previous session (`keepalive`) or whether we're
automatically setting up a new session (`auto_login`).

So currently if *either* `keepalive` or `auto_login` is `true` and
`authentication` is set to `login`, then Converse will try to log the
user in.