feat: remove channel upgradability (#8008)

* feat: remove channel upgradability

* lint

* basic migration setup

* feat: remove channel upgradeability

* fix docs

* register v10 migration in app module

* error on upgrading channels + code review fixes

docs/docs/02-apps/02-interchain-accounts/01-overview.md

@@ -45,4 +45,4 @@ This means that the host and controller modules cannot close channels, but they
 
 In the event of a channel closing (due to a packet timeout in an ordered channel, for example), the interchain account associated with that channel can become accessible again if a new channel is created with a (JSON-formatted) version string that encodes the exact same `Metadata` information of the previous channel. The channel can be reopened using either [`MsgRegisterInterchainAccount`](./05-messages.md#msgregisterinterchainaccount) or `MsgChannelOpenInit`. If `MsgRegisterInterchainAccount` is used, then it is possible to leave the `version` field of the message empty, since it will be filled in by the controller submodule. If `MsgChannelOpenInit` is used, then the `version` field must be provided with the correct JSON-encoded `Metadata` string. See section [Understanding Active Channels](./09-active-channels.md#understanding-active-channels) for more information.
 
-When reopening a channel with the default controller submodule, the ordering of the channel cannot be changed. In order to change the ordering of the channel, the channel has to go through a [channel upgrade handshake](../../01-ibc/06-channel-upgrades.md) or reopen the channel with a custom controller implementation.
+When reopening a channel with the default controller submodule, the ordering of the channel cannot be changed.

docs/docs/03-light-clients/01-developer-guide/08-proposals.md

@@ -8,7 +8,7 @@ slug: /ibc/light-clients/proposals
 
 # Handling proposals
 
-It is possible to update the client with the state of the substitute client through a governance proposal. [This type of governance proposal](../../01-ibc/07-proposals.md) is typically used to recover an expired or frozen client, as it can recover the entire state and therefore all existing channels built on top of the client. `RecoverClient` should be implemented to handle the proposal.
+It is possible to update the client with the state of the substitute client through a governance proposal. [This type of governance proposal](../../01-ibc/06-proposals.md) is typically used to recover an expired or frozen client, as it can recover the entire state and therefore all existing channels built on top of the client. `RecoverClient` should be implemented to handle the proposal.
 
 ## Implementing `RecoverClient`
 

docs/docs/05-migrations/02-sdk-to-v1.md

@@ -112,7 +112,7 @@ app.IBCKeeper = ibckeeper.NewKeeper(
 
 ### UpdateClientProposal
 
-The `UpdateClient` has been modified to take in two client-identifiers and one initial height. Please see the [documentation](../01-ibc/07-proposals.md) for more information.
+The `UpdateClient` has been modified to take in two client-identifiers and one initial height. Please see the [documentation](../01-ibc/06-proposals.md) for more information.
 
 ### UpgradeProposal
 

docs/docs/05-migrations/12-v8-to-v8_1.md

@@ -23,7 +23,7 @@ There are four sections based on the four potential user groups of this document
 
 ### `04-channel` params migration
 
-Self-managed [params](https://github.com/cosmos/ibc-go/blob/v8.1.0/proto/ibc/core/channel/v1/channel.proto#L183-L187) have been added for `04-channel` module. The params include the `upgrade_timeout` that is used in channel upgradability to specify the interval of time during which the counterparty chain must flush all in-flight packets on its end and move to `FLUSH_COMPLETE` state (see [Channel Upgrades](../01-ibc/06-channel-upgrades.md#) for more information). An [automatic migration handler](https://github.com/cosmos/ibc-go/blob/v8.1.0/modules/core/module.go#L162-L166) is configured in the `04-channel` module that sets the default params (with a default upgrade timeout of 10 minutes). The module has a corresponding [`MsgUpdateParams` message](https://github.com/cosmos/ibc-go/blob/v8.1.0/proto/ibc/core/channel/v1/tx.proto#L435-L447) with a `Params` field which can be specified in full to update the module's `Params`.
+Self-managed [params](https://github.com/cosmos/ibc-go/blob/v8.1.0/proto/ibc/core/channel/v1/channel.proto#L183-L187) have been added for `04-channel` module. The params include the `upgrade_timeout` that is used in channel upgradability to specify the interval of time during which the counterparty chain must flush all in-flight packets on its end and move to `FLUSH_COMPLETE` state). An [automatic migration handler](https://github.com/cosmos/ibc-go/blob/v8.1.0/modules/core/module.go#L162-L166) is configured in the `04-channel` module that sets the default params (with a default upgrade timeout of 10 minutes). The module has a corresponding [`MsgUpdateParams` message](https://github.com/cosmos/ibc-go/blob/v8.1.0/proto/ibc/core/channel/v1/tx.proto#L435-L447) with a `Params` field which can be specified in full to update the module's `Params`.
 
 ### Fee migration
 

docs/docusaurus.config.js

@@ -119,13 +119,6 @@ const config = {
             docsPluginId: "adrs",
             label: "Architecture Decision Records",
           },
-          {
-            type: "doc",
-            position: "left",
-            docId: "intro",
-            docsPluginId: "tutorials",
-            label: "Tutorials",
-          },
           {
             type: "docsVersionDropdown",
             position: "right",
@@ -275,16 +268,6 @@ const config = {
         exclude: ["**/*.template.md"],
       },
     ],
-    [
-      "@docusaurus/plugin-content-docs",
-      {
-        id: "tutorials",
-        path: "tutorials",
-        routeBasePath: "tutorials",
-        sidebarPath: require.resolve("./sidebars.js"),
-        exclude: ["**/*.template.md"],
-      },
-    ],
     [
       "@docusaurus/plugin-content-docs",
       {