Comprehensively retry poll/register even on unforeseen errors

[gnprice]

This is a followup to:

• Retry registerQueue #556
• Retry long-poll failures, with backoff #184
• Start new event queue when old one has expired #185

Hopefully with #556 (fixed by #561) we're done with needing to add try/catch blocks and retries for conditions that can happen for purely operational reasons like the device going to sleep. But there might be another such condition we've missed; and there's also always the possibility of bugs in our code. In particular the event-poll loop calls PerAccountStore.handleEvent, which can reach quite a lot of our model code because of the variety of different events, so it's probable that at some point we'll have a bug that causes that to throw an exception.

For the bulk of our code, if a bug causes an exception, then the best thing to do is to let it propagate out of our code uncaught — it'll mean that that widget doesn't get built (causing a gray rectangle in release builds), or that user gesture doesn't get acted on, but the user can pick up from there and try again. But the event loop, or UpdateMachine, is different: it's the one spot in our code where we have a persistent thread of control flow of our own. It needs to keep itself going no matter what happens, because nothing else will resume it for us.

I have a rough draft for this, which I wrote while working on #556/#561. I put it aside in order to get #561 out the door promptly, but I'll plan to pick it up later. The draft also comes with some user feedback, a form of #555.

Related issues, some of which might end up getting handled at the same time as this one:

• Show "Connecting…" banner (or equivalent) when server data is stale #465
• Show detailed poll-failure feedback, in beta #555
• Handle unrecoverable long-poll failures #186
• Reset backoff interval after successful connection #554

[PIG208]

The referenced draft seems to be https://github.com/gnprice/zulip-flutter/tree/dev-retry. I can pick this up to work on #555.

[gnprice]

This came up again at #809 (comment) (though that happened to be a false alarm). As I wrote there, restating the main substance of this issue but more briefly:

When we throw an exception from within PerAccountStore.handleEvent, that represents a bug but we can and should recover from it:

• we should show the user an error dialog (for the beta, i.e. Show detailed poll-failure feedback, in beta #555),
• and then replace the store the same way we do when the event queue expires (i.e. this issue Comprehensively retry poll/register even on unforeseen errors #563).