Support legacy recover client proposal for v8 in-flight proposals

[colin-axner]

Summary

v8 currently removes two proposals:

• legacy ibc software upgrades
• legacy recover client

I recommend the following:

For legacy IBC software upgrades, leave as deleted, but add checks in the upgrade test to v8 to ensure that in-flight upgrade proposals safely fail after the upgrade. The reasoning for leaving deleted is the fact that the chain is already undergoing a software upgrade and it is not recommended to be proposing the next software upgrade during a software upgrade. This is an edge case situation and I would recommend allowing this proposal to naturally fail, requiring the chain to resubmit using the new proposal type.

For legacy recover clients, revive the proposal type, mark it as deprecated and modify the legacy proposal handler to convert the legacy type into the new msg recover client type. The msg recover client handler can then be used to execute the legacy proposal type. Support for in-flight legacy recover client proposals will be made for v8, but given that it is deprecated, chains should use the new proposal type to avoid in-flight client recovery failing when upgrading to v9. Additional checks should be added for legacy handling in the upgrade test

The migration docs should be updated accordingly.

Thank you @alpe for pointing out that proposals may be in-flight at the time of the upgrade.

---

For Admin Use

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

[damiannolan]

Thanks for creating the issue @colin-axner