Simplify our app.go

[ValarDragon]

As evidenced in the v5 upgrade, our app.go is ridiculously complex. The bug got introduced here dedcfb8#diff-0f1d2976054440336a576d4%5B%E2%80%A6%5D13012bce0e3c425819b7L342-R360 , but honestly the root cause imo is that this entire file is needlessly complex, where the order of every single line matters. It must be made more modular.

• Move upgrade migration logic into its own folder, /upgrades/v3, /upgrades/v4, etc.
• Make initParmsKeeper a general function somewhere, don't manually list out each module name. (Maybe this gets upstreamed to the SDK)
• Make app.go boilerplate methods go into their own file #713

To goalpost, app.go is currently almost 1000 lines long. Lets first try to get this to under 500 lines.

[ValarDragon]

I think we should make an AppKeepers struct, which has references to every keeper. Then OsmosisApp maintains a reference to the AppKeepers.

Then we make AppKeepers.InitializeKeepers and AppKeepers.SetupHooks as two cleanly divided methods.

[faddat]

@ValarDragon this would surely reduce a lot of boilerplate in app.go

[daniel-farina]

ref #697

[ValarDragon]

Closing the tracking issue as the most important part is done, and #713 captures the remaining small component (that is still wanted / a PR would be very appreciated, but not at all a priority)

[voluntatis-summ]

I think we should make an AppKeepers struct, which has references to every keeper. Then OsmosisApp maintains a reference to the AppKeepers.

Then we make AppKeepers.InitializeKeepers and AppKeepers.SetupHooks as two cleanly divided methods.

@ValarDragon A side effect... other packages will have to access the App keepers like this app.Keepers.StakingKeeper?
applies to mainly test files that I see... inside "/x" directory

[ValarDragon]

Yeah, I don't think the keepers struct is worth the tradeoff. (You could make the main app 'inherit' all of those, but its still not great)

I actually tried writing the AppKeepers struct, before then switching to the solution of everything be a pointer