Show detailed poll-failure feedback, in beta

[gnprice]

This is a followup to:

• Show "Connecting…" banner (or equivalent) when server data is stale #465

We seem to be sometimes failing to poll the event queue, even after #185 and #184, for reasons that aren't yet clear; see chat thread. To help us pin that down, it'd be good to show some more details to the user while it's happening. So when we hit any kind of error in polling the event queue, let's show that error to the user.

A straightforward and discoverable way to do that would be with a toast. So let's start with that.

We could also subsequently build a bit more elaborate of a system where we record the message in some kind of in-app log, and then have a screen the user can navigate to that shows the error log. We don't yet have a settings screen at all, though, so there'd be some UI work to do to even have a place to put that screen (in addition to building the log UI itself).

[PIG208]

I think detailed poll-failure feedback is valuable for unforeseen errors. Going ahead with the linear indicator for #465, most common transient errors (unless they persist) do not need a toast. This will help with the noise issue if we only show a toast for all kinds of poll-failure.

[PIG208]

Because our compose box is a part of the body on the Scaffold, Flutter's SnackBar does not know to avoid blocking it. Normally if there is a bottomNavigationBar (e.g. in light box pages) or a floating action button, the snack bar could float above and even animate y offset change when navigating between different pages.

An option might be moving the compose box to bottomNavigationBar, but we will need to find a fix to address the MediaQuery change when the keyboard is shown. There are also options like making a placeholder bottomNavigationBar or creating a custom SnackBar. Will need to experiment a bit to see if any of them is feasible. There could be some easier alternatives that I'm not aware of.

[PIG208]

Because such poll-failures can be critical and rare enough that it's fine to block the compose box, it is not necessary to handle this issue if it turns out to be too much work. We can work on a simple SnackBar-based implementation for now.

[gnprice]

Yeah, rearranging the compose box or customizing SnackBar is definitely out of scope for this issue — if the notices obscure the compose box and we decide that's annoying, that's still fine for launch and any customizations like that would be a post-launch issue.