Stop sleep-induced backoff upon waking

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 https://github.com/zulip/zulip-flutter/issues/979#issuecomment-2495150102. 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 https://github.com/zulip/zulip/pull/12926 and https://github.com/zulip/zulip-mobile/issues/3916 (which we'll migrate into this repo's tracker); it's related also to #477.

References

• Previous issue with related symptom: #979
• Different issue with related symptom:
  • https://github.com/zulip/zulip-mobile/issues/3916
  • https://github.com/zulip/zulip/pull/12926
  • #477