It is possible that after migration users would already have Firefox PWAs on
their screen.
Since they already know about this functionality, we should not promote it to
them with the one-off `FirstTimePwaFragment`.
To query installed PWAs we'll use an API available only on Android >= 26 which
means that we will probably have half of users with PWAs still see the
onboarding but half which will not.
This avoids BuildConfig modifications between local dev builds,
and speeds up the builds by avoiding running tasks that depend on BuildConfig.
Locally, depending on exact build circumstances, this saves about 5% of build runtime
for simple code changes, and about 90% of build runtime for no-op builds.
Initially we didn't want to do that since we do not need to cache dependencies from our own
maven repository. But Android Components can introduce other third-party transitive
dependencies from other repositories (like Android X) and those need to be cached.
Problem was that we were trying to process menu changes (in response to account manager events) on some background thread as that's what account manager emits them on, so some code internally in PopupWindow's dismiss handling (i think, didn't dig very deeply here) was silently giving up and we'd get into a bad state.
The reason this seemingly only happened if you quickly opened a menu on startup is because account manager isn't initialized until sometime after the startup finished. So the trick was to open the menu (and register account manager state callbacks) before it got initialized, so that the callbacks are invoked.
This should also reproduce in other, much more obscure ways, e.g. if you open the menu right before sync is scheduled to run in the background, change FxA password on another connected client, and then eventually receive a onAuthenticationProblem callback.
