ibc: add support for host chain upgrades

[conorsch]

Some upgrades of the host chain (e.g. Penumbra) might break clients on counterparty chains. To mitigate this we need to implement a loosely specified IBC upgrade mechanism in the same style as ibc-go's UpgradeProposal which, in a nutshell, consists of committing the client and consensus states at a known key.

[erwanor]

There are two strategies that we can take to implement this. The first one is to pre-commit on an upgraded ClientState[^1] during the governance process. One idea is to have upgrade proposals embed an Option<ClientState> that is used during proposal enactment. This approach is possible because unlike consensus state, parameters like a ProofSpec or a chain identifier are static. Another approach is to fold the upgraded client state as part of the migration process that node runners decide to perform.

pub struct ClientState {
    pub chain_id: String,
    pub trust_level: Option<Fraction>,
    pub trusting_period: Option<Duration>,
    pub unbonding_period: Option<Duration>,
    pub max_clock_drift: Option<Duration>,
    pub frozen_height: Option<Height>,
    pub latest_height: Option<Height>,
    pub proof_specs: Vec<ProofSpec>,
    pub upgrade_path: Vec<String>,
    pub allow_update_after_expiry: bool,
    pub allow_update_after_misbehaviour: bool,
}

[erwanor]

In #3703, I removed the ChainParameters struct and moved its chain_id field to the AppParameters. However, I did not add a chain_id field to the ChangedAppParameters of the governance interface. My reasoning is that changing the chain id without going through the host chain upgrade process (this ticket) is automatically IBC breaking. I feel like it's better to add support for chain id changes at the same time we implement this ticket, rather than leave it as a landmine.

[hdevalence]

Do we need to implement this prior to mainnet?