Come up with long-term strategy for managing view data management

[BenHenning]

The current solution for view-specific data management has a few issues:

• View models are currently fragment-bound, which means they easily leak the fragment state OR aren't true view models (e.g. are recreated when fragments are recreated)
• Passing data between fragments involves a lot of additional boilerplate by funneling through common ancestors

#147 may help solve the second point, but the first one needs additional thinking. In general, we should:

1. Come up with a holistic strategy for how to cleanly store & pass view-specific data through the UI, taking into consideration configuration changes, activity destruction & bundling, data-binding observers (see Convert all ViewModels to ObservableViewModel #234), and processing live data observers
2. Determine an implementation plan & migration strategy for the current codebase
3. Break up the migration into smaller pieces that are filed as separate issues, then drive this migration effort (this is a good project to parallelize among contributors)

This issue will be the top-level issue tracking the above.

[BenHenning]

NB: part of this may also involve simplifying our current interface set up for the state/question fragments since there are quite a few listeners now, and some seem closely related (I think there are actually some situations where synchronous events are moving up and down the UI hierarchy a couple times for simple operations). While there's not a serious performance concern here (and likely not a concern with leaks either), it does introduce a bit of complexity which makes tracking down handlers & origins of events harder.

[BenHenning]

Also maybe a better way to be thinking about this might be to consider both how data should be stored, and how it should be passed in the UI level. For each of these I think there are a few categories.

Places to store data:

• Presenter: for data that does not need to survive across configuration changes or state loss
• View model: for data that should survive configuration changes but doesn't need to survive state loss
• Bundles: for UI-specific data that should survive state loss
• Domain controllers: for application state that should survive state loss (including persisted data)

Ways to transfer data:

• Intents & argument bundles: for parameters used to initialize an activity/fragment
• Events/listeners: for transient data that needs to be passed across UI component boundaries (generally up the UI hierarchy--all data to components at the same level or below another component must go through abstract listeners via a common ancestor that directly calls down without storing fragment/view references)
• Via domain controllers: this should only be done for data that falls under the type of data stored here per the above list

We should think through the above & see if any other cases should be added, or if we should handle data in a different way than the above. Otherwise, if that looks good we can optimize our approaches to simplify the above. We should also come up with typical use cases, examples, and best practices around each of the above to make things a bit more structured.

[BenHenning]

One idea I just had: we could automatically generate a true view model by annotating compatible fields with something like @RetainAcrossConfigChanges. We could also similarly have a @RetainAcrossAppDeath, but perhaps we should just do both right away? I'm not sure since the former could be any non-lifecycle object, but latter has to be serializable (so it must be a proto).

This may go well with existing plans to generate fragment, activity, and view classes with corresponding presenters. Given the existing complexity around using injectable classes in view models, and the conflation between Oppia and Jetpack view models, it may be the best just to move off of view models entirely (but still leverage their benefits via code generation). However, this is not going to work well with databinding since our entire approach is utilizing view models to interact with views, so we should figure out a replacement for databinding OR figure out how this would work with Compose.

This also seems like the best option since:

• It's currently awkward to test view models directly (they're tested through their corresponding fragments currently).
• Activities mostly can't have view models.
• Using view models correctly such that they work in both Dagger and across configuration changes is pretty difficult, and avoiding it seems cleaner.
• Generally it makes more sense to keep all logic in one place (presenters) since view models are tightly coupled with presenters, anyway.