msglist: On new event queue, try to re-fetch messages before switching to new store

[gnprice]

In the original description of #185, I wrote:

After creating a fresh PerAccountStore, we can go on to create fresh MessageListView objects corresponding to each of those that are currently registered, and have them fetch messages corresponding to the range of messages the existing views have.

• This is one of the advantages of making a fresh PerAccountStore — those MessageListViews can refer to the new PerAccountStore while the old MessageListViews continue to refer to the old store, and there's no risk of inconsistent data from having an old view-model refer to a store with new data or vice versa.

My initial implementation of #185 won't quite do that, though: instead, when the new PerAccountStore is created, it promptly appears in all the PerAccountStoreWidgets for that account, and the message lists learn about it through _MessageListState.onNewStore:

  @override
  void onNewStore() {
    model?.dispose();
    _initModel(PerAccountStoreWidget.of(context));
  }

The effect is that the messages get fetched from scratch, just like when first navigating to the given narrow. On a slow connection, this means the messages the user had been looking at disappear for a while, replaced by a loading indicator. On a fast connection, there's a brief flicker of that blank page with loading indicator before the messages return, but the main effect is that the scroll position gets reset to where it started (because for a frame or two there was nothing to scroll through).

We should instead do something subtler, along the lines outlined in the quote above.

In tricky cases there are trade-offs to make: what if there are thousands of messages in the list (because the user scrolled far back in history), and we make some progress loading the corresponding messages but stall before we get them all? (Possibly the answer is we should just keep at it, and if the user wants to give up they can always navigate back out.) But at a minimum, the goal of this issue is: if there's just a single batch of messages in the list, and re-fetching them completes within a second, then the user should see the view just smoothly update without any hiccups.