Consistently clear old data on all ways of leaving an account

[gnprice]

Most of our reducers reset their state when they get one of the action types LOGOUT or ACCOUNT_SWITCH. Many of them treat LOGIN_SUCCESS the same way; but many others don't.

We should make a consistent pattern here, document it, and ideally refactor so that the pattern gets maintained naturally.

Here are some notes, based on #3213 (comment) which I wrote a couple of years ago (but updated):

• The three action types LOGOUT, ACCOUNT_SWITCH, LOGIN_SUCCESS don't appear in any sequence -- they correspond to completely independent actions in the UI, namely the "Logout" button; choosing an already-authenticated account in the account picker screen; and authenticating to an account we didn't have a key for.

  • I think this may mean there are live bugs here: if you're using one account, and then you go log into a new account, the various reducers that don't respond to LOGIN_SUCCESS won't reset the data.
    • They should discard the old data a bit later, at least, when they get a REALM_INIT action with the data from the new initial fetch.
    • I'm not sure this causes any live bugs, though, because it looks like we navigate to the loading screen in the loginSuccess action creator. So that may make the fact we haven't discarded the old data invisible, and then we should only leave the loading screen upon REALM_INIT.

• The action creators for those three action types all look like this -- there's a thunk action which triggers a navigation, and then dispatches a plain-old-object action:

const logoutPlain = (): Action => ({
  type: LOGOUT,
});

export const logout = () => async (dispatch: Dispatch, getState: GetState) => {
  NavigationService.dispatch(resetToAccountPicker());
  dispatch(logoutPlain());
};

• I think it'd be a useful refactor to consolidate one action type like CLEAR_ACCOUNT_DATA.
  • The action creators for these three (in accountActions.js) can dispatch that first, then also a LOGOUT etc.
  • Almost all the reducers would respond only to the CLEAR_ACCOUNT_DATA.
  • There are a couple of exceptions, like accountReducers and sessionReducers, that actually want to treat the three cases differently. Those would be the only ones to continue responding to LOGOUT etc.; and they'd stand out better as a result.
  • Then there are further changes we might make to those, but that'll be easier to see after that.

[gnprice]

See also #3822 for a related improvement we made more recently.

[gnprice]

Another issue with a similar flavor:

• Discard fetches when the active, logged-in account has changed #5009

[chrisbobbe]

Reopening because I missed a spot or two in my #5606; see #5612.