Remove AllowUpdateAfter usage from 07-tendermint clients

[colin-axner]

Summary

Disable recognition of AllowUpdateAfterExpiry and AllowUpdateAfterMisbheaviour

Problem Definition

Currently these parameters are intended to signal the recovery options for a client if they become expired or frozen. A governance proposal cannot overwrite a client if these parameters if they are set to false. However, a code migration can overwrite the client and consensus states regardless of the value of these parameters. Thus, I don't find value in enforcing these checks. If governance votes to overwrite a client or consensus state, it is likely governance is also willing to perform a code migration to do the same.

Proposal

Do not modify the client state. Leave the booleans there for signalling intent, but remove the enforcement checks. This will allow for easier means of client recovery

@cwgoes thoughts?

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[cwgoes]

You're completely right, these don't make sense given the possibility of code migration. I'm fine with leaving them there for signalling intent, but I'm also fine with removing them altogether, arguably signalling should be done elsewhere (e.g. in the text of a governance proposal).

[charleenfei]

@colin-axner I opted to remove the booleans entirely from the ClientState to avoid any kind of confusion regarding if they have effect or not. let me know if this should be revised to leave the booleans in --

[colin-axner]

The booleans cannot be removed as this changes the encoding of the ClientState. Connection handshakes to chains without this change will fail as they will be trying to verify the old client state, thus breaking IBC backwards compatibility

[colin-axner]

We can mark them as deprecated and if we ever implement a way to modify the client state without breaking new connection handshakes, then we can remove them

[colin-axner]

closed by #1118