Go directly on launch to inbox / home view

[gnprice]

Currently when you launch the app, you get the "Choose account" screen; then when you choose an account, there's a loading screen followed by the "Home" screen, the one with "🚧 Under construction 🚧" and several buttons; then you can tap one of those like "Inbox" to get to a view that actually tells you about what messages you have.

This is a bit cumbersome, and particularly so because that loading screen before "Home" can take several seconds as it's loading the whole register-queue response from the server. (It's several seconds for a large realm like chat.zulip.org from a good network connection; a fraction of a second for a small realm; and can of course be longer on a slow network connection.) So you launch the app, tap a button, then have to wait several seconds before you can tap the next button to get to the inbox.

It'd be good to instead open directly to whatever account you were last looking at some account (bypassing the choose-account screen) and to the inbox or another informative home view (bypassing the "Home" screen). See chat discussion, and later followup.

• Update: I've split out the "account you were last looking at" part as a followup issue: On launch go to last account used, not just first in list #524

Specifically, a minimal version of this can just always go to the inbox. A possible future extension is #517, to let the user choose between the inbox and other home views.

A couple of things we'll want to take care with in doing this:

• We'll need to make sure the user can easily get to the other views and to other accounts, by navigating "back" out of the initial screen. This should be straightforward to do by putting "Choose account" and "Home" on the navigation stack from the beginning.

  (Later we'll do something else for navigation — Overall app navigation for beta #311 — but that will work well enough for now.)

• Because the new initial screen requires server data, it'll initially just display as a loading screen. If that server can't be reached, the loading may never finish. In case what the user actually wanted was to use some other server, we'll want to make sure they can navigate away even while loading is ongoing.

The latter point probably means adjusting the loading screen so that it has an app bar which can hold a back button, even if there's little other meaningful information on the screen. We have this TODO already in the implementation of PerAccountStoreWidget:

  Widget build(BuildContext context) {
    // TODO: factor out the use of LoadingPage to be configured by the widget, like [widget.child] is
    if (store == null) return const LoadingPage();

and this issue will probably call for carrying out that TODO, then arranging for all the PerAccountStoreWidgets that represent whole pages in the navigation (which is most of them) to use a loading widget that is itself a whole page with a Scaffold.