Introduce an app store to hold state for the lifecycle of the app

[jonalmeida]

In #20687, we spoke about the value of an AppStore to hold state that needs to live as long as the app (or longer than the fragment).

With the introduction of UI state like the collapsible inactive tabs list, this is a good opportunity to create one and add it in there.

┆Issue is synchronized with this Jira Task

[jonalmeida]

We can possibly add top sites to this store as well.

Data classes are cheap.. we should consider holding more of the HomeFragmentStore at an app-lifetime state because it's the second more used screen after the browser.

The HomeFragmentStore is re-created multiple times and we don't need it to be.

[jonalmeida]

After talking to mcomella about tabs tray performance, there may be reason to move that state to the app store level too.

[jonalmeida]

As of now, I've landed an AppStore in Fenix that can be used to hold in-memory state during a warm startup. The store landed with a trivial flag for inactive tabs as an example use case.

When should you decide to use it?

There are various constraints to consider before using the AppStore for holding a feature’s state:

• Is persistence to disk NOT a requirement?
• Does the state need to exist for the entire lifetime of the app? Is it needed on frequently used screens?
• Is it safe to lose this state if the OS reclaims memory and the app is restarted?
• Are we using costly resources to fetch the data? E.g. network/disk IO.

Other possible uses

• Home screen: we have multiple sources of data on the home screen that use disk or network resources. We can potentially increase performance in warm startups or switching on a new tab if we persist this home screen state to an app lifetime store. Features like Top Sites, Pocket stories, and Recent bookmarks can all benefit.
• Account Manager: when a feature/UI screen needs to know the current state of the Account Manager, there is a complex observer/callback flow required to know when the account is in its final state. Instead of requiring each feature to implement this, we could add a simple state enum for those features to observe.
• Theme Manager: The Fenix BrowsingMode theme is stored in a separate class. It would be convenient to have this in the store too.
• Navigation: Similar to Focus, we could consider moving our navigation graph to a compiled state so that we can better understand and test the various navigation actions. I'm less inclined to do this however, since we've fully invested in the AndroidX navigation library at this point and it would be a significant amount of work to re-engineer it for no known savings.
• (Consideration) Experiments: would it be useful to have experiment slugs in this store instead when Nimbus is ready?