[Action Required] IBC patch upgrade at 2464000

[Action Required] IBC patch upgrade at 2464000\n\nThe v5 upgrade had a subtle bug that prevents creation of new IBC channels.\n\nNo current user funds are at risk, and the bug does not affect trading, LP, bonding.\n\nAll existing IBC channels function just as before, IBC deposits and withdrawals for existing assets are not affected.\n\nThe bug solely prevents new channels from being created, preventing new chains from connecting to Osmosis. Bug details at the end.\n\nThis proposal suggests doing an emergency height-gated hardfork upgrade to a v6 binary. This upgrade will not require any synchronous state migrations. The v6.0.0 software version is fully state-compatible with v5.0.0 until the upgrade block 2464000, at which point they diverge. This is the same upgrade mechanism as the Osmosis v3 upgrade (prop 17), used when the governance deposit mechanism was broken.\n\nThe proposed upgrade block height of 2464000 is estimated to be at December 20, 2021, 16:00 UTC (Monday).\n\nAll validators, and full node operators should update their software to version v6.0.0 prior to block height 2464000. After doing so, validators should deposit on this proposal.\n\nFailure to do so will cause the node to crash -- requiring a new node to be resynced, or restored to an earlier height with correct software version via snapshot.\n\n## Actionable(s)\n\n* Every node should upgrade their software version from v5.0.0 to v6.0.0 before the upgrade block height 2464000. If you use cosmovisor, just swap out the binary at upgrades/v5/bin to be v6.0.0, and restart the node. Do check that cosmovisor version says 6.0.0.\n* Upon upgrading their setup, every validator should place a deposit on this proposal to signal readiness for the upgrade. (1uosmo suffices)\n* Every node should check in between December 20th 4AM UTC and 4PM UTC, and see if 2/3rds of validators have put a non-zero deposit on the proposal. If so, no further action needed (unless they didnt upgrade yet, in which case they should). If 2/3rds of validators have not signalled readiness by this time, then the upgrade is considered to have not reached agreement, and all nodes should downgrade their binary back to v5.0.0 for further coordination.\n\n## Failure case and risks involved\n\nIn the case of critical failure where less than two-thirds of voting power updates their nodes, and over 1/3rd of voting power fails to downgrade according the plan, the new chain would fail to start. In this situation we propose coordination by social consensus on the Osmosis Discord - "validators" channel. (https://discord.gg/osmosis)\\n\\nNote: While not required, it is highly recommended for each validator to use the Tendermint KMS system to reduce the risk of potential double-signing if they fail to upgrade on time, and the upgrade proceeds.\n\n## Governance procedure\n\n A Yes vote on this proposal signals a desire to follow this plan to expediently recover the ability to create new IBC channels.\n A No vote on this proposal signals that another plan should be formed.\n\nDeposits are intended to be used by validators here.\n\n- Each validator signals their readiness and approval of this rocedure by depositing 1uosmo to this proposal from their validator operator key. Please do this, even if your validator operator key is behind a multisig. This is a good time to take advantage of authz, to allow easier depositing & voting.\n- Once over 66% of voting power has signalled readiness, this upgrade proposal is considered valid.\n- Should this proposal fail to gather readiness signalling from two-thirds of voting power by December 20th 4AM UTC, the upgrade proposal should be considered failed and validators should revert to the old binary prior to block 2464000.\n\n## Testing methodology\n\nThis upgrade has been tested to be compatible with v5.0.0 until the upgrade height on a testnet. This was done by having a v6.0.0 validator and a v5.0.0 full node peered to each other. Prior to upgrade height, both would reject channel open txs. Past upgrade height, the validator would accept channel opens, and the v5.0.0 full node would crash with a conflicting state hash (as expected). The v6.0.0 node could then receive IBC transfers.\n\n## Bug Details\n\nRelevant issue: osmosis-labs/osmosis #665\n\nTL;DR - There was a subtle misconfiguration in the Osmosis app.go. This slipped in from a copy-paste error during the SDK 42 -> 44 upgrade. This manifested in being unable to create new channels.\n