nav: Don't show a transition animation between 'loading' and 'main'.

[chrisbobbe]

A followup to #4249; see #4249 (review).

New in the recent React Navigation upgrades to v3 and v4, there's
now a transition animation when the loading screen exits. We don't
want to prolong the effect of the loading screen [1], so, get rid of
that exit animation.

Most accurately, we want to target the exit of the loading screen
and disable the animation there. But it seems that the
animationEnabled switch in navigationOptions operates on the
entrance of particular screen; I haven't found a similar option
for the exit of a particular screen.

A good workaround, to the extent that it's practical, would be to
tell all screens to disable their entrance animations if and only if
they're being reached directly from the loading screen. The only
reasonably simple way I can think of to implement this would be to
set defaultNavigationOptions to a function instead of an
object [2] and use that function's inputs to conditionalize on the
identity of the route being navigated from, i.e., the previous
route. Unfortunately, that doesn't seem possible; the navigation
object is the most likely-looking of those inputs, and logging shows
that it doesn't have data about the previous route, only the current
route (in navigation.state).

So, we use a heuristic: always cancel the entrance animation of the
main-tabs screen. This is supported by the following observations
(but naturally there may be edge cases I haven't considered):

• An extremely frequent and high-visibility action is to navigate
  from the loading screen to the main-tabs screen.
• We don't generally navigate from the loading screen to anywhere
  other than the main-tabs navigator.
• We don't generally navigate to the main-tabs screen from
  anywhere other than the loading screen.

[1] #4249 (review)
[2] The best link I've found for this is
https://reactnavigation.org/docs/4.x/headers/#using-params-in-the-title.

[gnprice]

LGTM, thanks! Please merge at will.

So, we use a heuristic: always cancel the entrance animation of the
main-tabs screen. This is supported by the following observations
(but naturally there may be edge cases I haven't considered):

• An extremely frequent and high-visibility action is to navigate
  from the loading screen to the main-tabs screen.
• We don't generally navigate from the loading screen to anywhere
  other than the main-tabs navigator.
• We don't generally navigate to the main-tabs screen from
  anywhere other than the loading screen.

I think there are a couple of exceptions but this is fine. In particular:

• I believe we only ever navigate to main, or to or from loading, under the control of the logic in navReducer.js (other than the default case that handles navigation actions.) Looking at navActions.js, there's no helper provided for navigating to either of them. And on the loading screen, there's no UI that offers navigation elsewhere.

• Looking at navReducer.js, the ways we can navigate to main are

  (a) on rehydrate, where we'll be starting from the initial state which is loading;

  (b) on INITIAL_FETCH_COMPLETE, and only in the case when the route at the bottom of the stack is not main. All the nav actions we dispatch are stack pushes and pops, so the route at the bottom of the stack changes only under the explicit logic in navReducer. The routes that appear there are realm, account, loading, and main. Barring race conditions which might exist but are bugs of their own if they do, we don't do initial fetch while on realm or account, so this too will happen only when on loading.

• On the other hand, the ways we can navigate away from loading are

  (a) on INITIAL_FETCH_COMPLETE, to main;

  (b) on LOGOUT, but that shouldn't be possible when on loading (again barring race conditions);

  (c) on rehydrate, to realm or account as well as main.

So in short if you launch the app and don't have an active, logged-in account, we will have a navigation from loading to a screen that isn't main; but that's the only such edge case. For most users this probably happens once, on first launch of the app. If the only way to fix that with the API we have would mean doing something complicated, then it's fine to leave as it is.