Store server data for multiple accounts at once

[gnprice]

Currently we store almost all data from the server -- things like what other users exist, what streams, what messages, and how many unreads you have -- for just one account at a time, the "active account" (see our glossary). When you switch to look at another account, that one becomes the active account, and we discard the data from the previously active account.

Instead, we should maintain all this data for all the user's accounts, all the accounts they're logged into.

This is a prerequisite for many of our issues in the "multi-org" area. In particular it's necessary for:

• showing unread counts on your other accounts, Add unread counts to account view #893
• a good quick experience switching to look at different accounts, Add quick organization switcher #1321 (because without the data, we have to fetch it all from scratch)

and helpful or likely-necessary for:

• Opening notification doesn't navigate to conversation, if in another account #4630 (there's an alternative solution described there, but it's really a workaround; if we had this data, we'd have fixed this long ago when we started navigating to the conversation on opening a notification in the first place)
• Use realm icons in organization switcher #392 (we could work around by sticking this data on state.accounts like we currently do for zulip_version and a few others, but that is a workaround)

We don't have to do this all at once. We can have intermediate states where some parts of the server data are kept only for the active account, and others are kept for all accounts.

In fact the status quo is such an intermediate state: we keep a handful of small pieces of server data in state.accounts, which is the one place that currently keeps data for all accounts. These include the Zulip server version and feature level, and the user's user ID.

Prerequisites for fully doing this include:

• We'll want to stop reloading the server data from scratch on app launch. As Store persistent data in a sound way #4841 explains, we currently rely on that to limit the consequences of some major issues in how we maintain the data. As Store persistent data in a sound way #4841 says:

  In principle I guess we could maintain all that data while keeping the reload-from-scratch-on-each-launch strategy; but it'd mean even more data getting reloaded from scratch, so even more lag.

  In order to do without that reloading, we'll need to fix:

  • Store persistent data in a sound way #4841, so the data doesn't get corrupted with partially-written updates
  • Ensure all server events and their operations are handled #3408, so we don't accumulate errors where we didn't notice something that changed on the server
  • and when we learn of new forms of event or events we aren't properly handling, we'll need to start prioritizing those issues and fixing them promptly. (With migrations to reload server data from scratch.)

  To get the full benefit, we'll also need to do Support downgrading to a long-lived event queue #3916 in order to maintain each server's data over hours, days, and weeks with the app in the background.

• We'll need to do some rearranging of how our data appears both in Redux and in persistent storage, because the existing schemas are built on the assumption of a single active account. I've filed this as Multi-org-compatible schemas for data in Redux and persistent store #5006.