Since #184, we retry long-poll failures, with exponential backoff up to an interval of 10 seconds.

Even after the device is again able to reach the server, though, the backoff interval on next failure remains 10 seconds, for as long as the app keeps running. That seems unhelpful. Instead, when we find we can again consistently reach the server, the backoff intervals should reset to what they would be if the app were restarted.

The simplest thing to do here would be: as soon as there's one more success, just reset the backoff to its initial state. I'm not sure if a more complex strategy would be best in general. But I think for these long-poll requests the simple thing is fine, for the reasons below.

Detailed reasoning

The possible risk in completely resetting backoff on a single success is that if the server is having trouble and handling some but not all its requests, that plan would mean we'd do a lot more retries, partway toward what would happen if we weren't backing off at all. I'm not sure if there's a standard recommendation for how to strike a balance there.

However, these particular requests are a long-poll — which means that a successful request most often takes a long time to come back: up to 60 seconds. Probably most of the time it's longer than our max backoff interval of 10 seconds. So if after that, our next request randomly fails (because the server is having trouble) and we retry in 100ms, that's not that different from if we retry after 10 seconds.