feat: incentive accumulator migration

[p0mvn]

Closes: #XXX

What is the purpose of the change

This PR introduces incentive accumulator migration to address the truncation issue with pool 1423.

In the v23 upgrade, we introduce a scaling factor to avoid truncating the per-unit-of-liquidity incentive accumulator. See: #7409

The goal is to have all the newly created pools utilize this accumulator. At the same time, we want to migrate the old pools that are currently affected (e.g. pool 1423). We also want to migrate only the affected pools to limit migration risk.

To achieve all of the above, this PR:

• Introduces a pool ID threshold snapshotted during the upgrade to state. After this threshold, all newly created pools utilize the scaling factor.
• A hard-coded map of pool IDs that are below the threshold but migrated to the scaling factor logic

In the core module logic, we dynamically select the scaling factor based on the pool ID to apply to the accumulator.

Given successful migration, we will migrate the remaining pools in a future upgrade.

Testnet

Pool ID threshold is selected dynamically based on either mainnet or testnet state.

For any environment other than osmosis-1, we avoid performing pool migration to avoid dealing with complexity. This is. fine as we don't care about other environments potentially truncating with older pools.

Testing and Verifying

• Test core helpers
• Test upgrade handler
• Test genesis

Documentation and Release Note

• Does this pull request introduce a new feature or user-facing behavior changes?
• Changelog entry added to Unreleased section of CHANGELOG.md?

Where is the change documented?

• Specification (x/{module}/README.md)
• Osmosis documentation site
• Code comments?
• N/A

[p0mvn]

Note: will extend the pool IDs separately

[ValarDragon]

Logic looks good to me, but im really worried about migration times. Should wait until we've tested it out ofc, but I suspect we may need to do something more lazy here.

Or at minimum split it up so we only migrate one pool at a time. (or maybe theres a clever way to only have to migrate nearby ticks immediately or smth)

[czarcas7ic]

Well done, logic appears sound to me.

Of course need to benchmark to ensure no issues with duration of migration, but other than that LGTM.

[AlpinYukseloglu]

LGTM, nice work. Iterating over ticks for migration seems unavoidable, so we'll have to see how migration time looks on benchmarks.

Since there's no long term loss to delaying the migration, we could also potentially split it up (would need to discuss what a non-hacky way to do this would be)