Stop sleep-induced backoff upon waking

[gnprice]

When you return to the app after it was in the background, or the device was asleep/locked, we often spend several seconds with the loading indicator going before we resume getting events from the server.

This issue is about one cause of that symptom, described previously at #979 (comment). Copying that description and adapting slightly:

• The device goes to sleep, perhaps while the app was in the foreground; or the user switches to another app, putting Zulip in the background.
• The app actually keeps running — one can tell because it keeps printing log messages to the console.
• But it isn't able to make network requests.
  • The symptom of this is that the requests fail with SocketException, generally with DNS errors that it can't find chat.zulip.org (or whatever the host is).
    • We'd previously seen that those errors are common; that's why they're the one type of transient failure we silenced from reporting to the user, in Show poll-failure details #868.
  • In retrospect this makes sense as a compromise for the OS to choose: let the foreground app keep running, at least for a little while, in case the user wakes the device right back up again; but disable the network, because the wifi radio and especially the cell radio are expensive for the battery.
• So our event-poll loop keeps getting failures, and backs off farther and farther. So far, so good.
• Now the user wakes the device, and the app is able to use the network again. But…
• We may be in the middle of a long backoff. So it could be up to 10 seconds (typically more like 3 seconds) before we make the next request. During the remaining backoff time, the loading indicator will continue; and we won't learn of new events, even events that already happened while we were offline.

(We used that other issue thread #979 to track a different cause which produced a much longer-lasting (up to a minute) version of this symptom, and so closed that issue when that was fixed.)

Out of scope

Another cause of a similar symptom can be if the device's event queue has been discarded by the server as expired.

That version has a distinct further symptom: if you're looking at a message-list page, then after the linear progress/loading indicator at the top has stopped, the messages disappear and are replaced briefly by a spinner while the messages are reloaded. (That's because the app refetches messages after getting a fresh queue.)

That cause is tracked separately as zulip/zulip#12926 and zulip/zulip-mobile#3916 (which we'll migrate into this repo's tracker); it's related also to #477.

References

• Previous issue with related symptom: Loading indicator slow to go away when returning to app, though in fact up to date #979
• Different issue with related symptom:
  • Support downgrading to a long-lived event queue zulip-mobile#3916
  • events: Add basic downgradeable event queue support. zulip#12926
  • Have data ready on app startup #477

[gnprice]

To fix this, we'll need to:

• notice when the app or device had been offline — so explore what APIs are available to us to observe this status, and try out their behavior empirically to help understand just what they're telling us;
• set up a listener so as to notice promptly when the app/device comes back online;
• when that happens and we're in the middle of a backoff that can be attributed to the previous status, abort the backoff and immediately make a fresh getEvents request.