Revisit logic for IBC gov updates

[alpe]

There have been refactorings in this area and we need to test this work with V3

• IBCClientUpdate
• UpgradedClientState

See ExecuteGovProposal unpackInterfaces

See https://github.com/confio/tgrade/blob/v1.0.1/x/twasm/contract/incoming_msgs.go#L61

[daniellarita]

@alpe I see this ticket doesn't have an epic. Is this one necessary for mainnet mvp?

[alpe]

yes, we need to address the changes that came with v3 or we won't be able to do ibc client upgrade (for the rescue)

// Deprecated: UpgradedClientState field has been deprecated. IBC upgrade logic has been
// moved to the IBC module in the sub module 02-client.
// If this field is not empty, an error will be thrown.
google.protobuf.Any upgraded_client_state = 5
[deprecated = true, (gogoproto.moretags) = "yaml:"upgraded_client_state""];

[alpe]

Our version is incompatible. I have opened for further discussions

• Fix ClientUpdateProposal for IBC v3 poe-contracts#142
• Add UpgradeProposal for IBC v3 poe-contracts#143

When the contract is modified, the binding(s) in tgrade needs to be fixed, too.

[ethanfrey]

Very good eye @alpe
Really hard to keep compatibility with multiple versions.

For tgrade-specific features (eg. these proposal types), let's consider ibcv3 as minimal supported version. If they change it again in ibcv4 or such, we will have to deal with migrations, but not til then.

[daniellarita]

We can add this as a top priority to the first post-launch release. Martin doesn't expect us to have IBC up and running on day one as there is nobody using the chain to begin with (until the first businesses are onboard)