feat!: add force withdrawal migration to remove liquidity module on Gaia

[dongsam]

Description

Force Withdrawal:

• first step : forcefully withdraw all pool coins of holders that exist in the Cosmos Hub except for ibc escrowed coins, and delete all pool states, This would be done during the first upgrade, which could be Gaia v10.
• second step : completely remove the liquidity module on the codebase and app during the second upgrade, which could be Gaia v11.
• pros : remaining pool coins can be withdrawn/burned as much as possible.
• cons : forced withdrawal is an artificial action that changes the account balance and requires extensive testing and simulations.
• For accounts that may be module accounts because they don't have Pubkey like the IBC escrow acc, pool coins should not be forcefully withdrawn as this may cause problems when the pool coins return via IBC.

Progress ( based sdk 0.45.x )

• bump ConsensusVersion from 2 to 3 for migration
• bump cosmos-sdk, tendermint for gaia v10
• add force withdrawal logic on migration
• add test cases
• simulation
• handling remaining reserve coins on module accs after force withdrawal (community fund)
• delete all pools and pool batches

Simulation

liquidity module force withdrawal simulation result (cosmos-hub state height 14922680 based)

• addresses_having_poolcoins_[before]
• addresses_having_poolcoins_[after]
• pools_state_[before]
• pools_state_[after]

Decision

• It is necessary to decide how to handle the reserve coins for the pool coins remaining in the 10 module accounts after the forced withdrawal, whether to send them to the community fund or leave them at the reserve addresses
• -> Decided to send to community fund in this issue

Ref

• Removal of the Liquidity Module on Gaia cosmos/gaia#2346

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (release/v1.6.x@c2fad97). Click here to learn what that means.
The diff coverage is n/a.

❗ Current head cfb7189 differs from pull request most recent head 330ce8f. Consider uploading reports for the commit 330ce8f to get more accurate results

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@                Coverage Diff                @@
##             release/v1.6.x      #30   +/-   ##
=================================================
  Coverage                  ?   33.45%           
=================================================
  Files                     ?       44           
  Lines                     ?    12601           
  Branches                  ?        0           
=================================================
  Hits                      ?     4216           
  Misses                    ?     7888           
  Partials                  ?      497           

[sainoe]

Thanks @dongsam! Just have a few comments on some potential simplification and documentation.
Great work!

[dongsam]

Thank you for your kind and detailed review @sainoe. I left a comment on the review and push the commit that applied the suggestions.

[yaruwangway]

if FundCommunityPool failed, no return err ?

[dongsam]

Yes, The FundCommunityPool is a very
simple function that is all about Send, Get, Add, and Set. In general, it is difficult to reproduce the failure and the probability of failure is close to zero, so error handling was not performed. Even if all of the previous logic succeeded and failed at the here, rather than reverting the entire migration by returning the error, it can be solved by re-calling only the FundCommunityPool function in the subsequent upgrade, so I don't think it's necessary to revert.