Don't allow connecting to ancient servers.

[chrisbobbe]

We currently have a ServerCompatBanner to warn the user if they're connected to a Zulip server that's on a version we don't support anymore, and ask them to nag their admin to upgrade, with a link to instructions. The threshold for showing that nag banner is currently 2.1.0 3.0, since #5334; that version number is meant to be updated along with https://zulip.readthedocs.io/en/stable/overview/release-lifecycle.html#compatibility-and-upgrading.

We should have a different threshold that's lower than the nag-banner threshold, so that for very old servers we just refuse to connect to the server at all, since we will have cleared out relevant backward-compatibility code.

Since our backward-compatibility code includes code for handling obsolete shapes of push-notification payloads, we should also make sure we're not trying to give users push notifications. This may happen naturally, if "refuse to connect" means logging the user out and deregistering them for push notifications. Since the deregister request can fail, we may also want to make the native code aware of logged-in state and filter out notifications for accounts that aren't logged in.

[gnprice]

(I just tweaked the description to get the word "old" in there, so that this issue comes up on a wider range of search queries one might try when looking for it.)

[gnprice]

Cross-linking some work so far on this issue: #5100, #5192, #5218. Copying from the description of that last PR:

This will let us get a better idea of how many (or few) users will be affected as we drop support for an old version, or as we remove compatibility hacks for old versions we already say we don't support.

In particular, I have a draft branch to start relying on server 2.0+, following up on #5192. One of the main things it does is clean up how we send messages, to use stream IDs and user IDs instead of emails and stream names. That'll be a much-appreciated improvement… but it will also mean we break some pretty core functionality for any users interacting with a server that's still on a pre-2.0 version.

We announced rather a while ago, the middle of last year, that we were no longer supporting such old versions. We even started showing a warning banner for any users on such a server, and haven't heard a peep from users seeing it. So we aren't going to shy away from making that change. But it might be the cue for us to start outright refusing to operate on those servers, as discussed at 401b3a2. Knowing how many users are still in this situation will help us decide whether to build that now.

This will also help us decide when it's a good time to drop support for server 2.1 and start requiring server 3.x+, and so on in the future.

[gnprice]

I think the next step here is to develop a PR that has us refuse to connect to a server older than 2.0.

That's quite a bit looser than the range we actually say we support, and will affect a very small fraction of users, keeping the risk quite small. It will also already let us start making many of the cleanups mentioned above.

After that's been out in a release and nothing's gone wrong, we can promptly bump the threshold to Zulip Server 2.1 -- still older than we actually support. Then consider bumping it to Zulip Server 3.0 (which is now over two years old), reflecting our actual stated support.

For implementation, note the bit about push notifications in the issue description above.