Upgrade to IAVL 1

[mhofman]

What is the Problem Being Solved?

We are experiencing slowdowns related to large state on mainnet. In particular, iteration during state-sync export / restore, and pruning after large data migrations. Those problems are supposed to be mitigated with IAVL 1, which is default for new chains in cosmos-sdk 0.50, and supposed to be compatible with older SDKs as well.

Description of the Design

Investigate what it would take to switch to IAVL 1 once we reach cosmos-sdk 0.47, optionally how to migrate an existing state (for both pruned states and archive node states), and if it solves some of the performance issues as expected: perform state-sync, measure pruning perf after a large state update like the one needed for #7212

Security Considerations

TBD

Scaling Considerations

Is there a way to perform at least part of the migration offline? Should we attempt to migrate archive nodes? Should a migration be done manually through state-sync restore?

Test Plan

A genesis export cannot be used to test this kind of migration since by definition it prunes the state.
However if the IAVL DB is really a drop in replacement, it might be a non consensus affecting change, meaning a hot patch might be enough to test.

Upgrade Considerations

Should be deployed as a chain software upgrade as a precaution.

[JeancarloBarrios]

This will be solved as part of.50 upgrade