Remove legacy governance v1beta1 handler for `ClientUpdateProposal`

[crodriguezvega]

After completing the migration to v8, it should be safe to remove the handler.

• [ ] Remove NewClientProposalHandler and call in app.go .
• [ ] Remove e2e test TestClientUpdateProposal_Succeeds.
• [ ] Add link to the PR completing these changes in the v8 to v9 migration docs.

[crodriguezvega]

Is it safe to completely remove also (can open a separate issue) the messages for ClientUpdateProposal and UpgradeProposal?

[DimitrisJim]

Is it safe to completely remove also (can open a separate issue) the messages for ClientUpdateProposal and UpgradeProposal

what would happen if we removed these (and the route in app.go) and we have an inflight prop? Looking at the route in gov, we should panic when calling GetRoute (I recall these being caught but can't find specific code in sdk for it atm).

edit: okay, seems it does a HasRoute before we get it in ExecLegacyContent, should definitely test for that case tho

[crodriguezvega]

what would happen if we removed these (and the route in app.go) and we have an inflight prop? Looking at the route in gov, we should panic when calling GetRoute (I recall these being caught but can't find specific code in sdk for it atm).

Yes, this was the issue that could have occurred in the upgrade to v8, but if I remember correctly, we agreed that for the next major upgrade we should remove them. If a chain upgraded to v8 then they should start using the new gov v1 messages and not continue using the deprecated ones.

[DimitrisJim]

considering I haven't seen folks respecting not using deprecated parts of API :laughing: I'd at least wanna make sure that rm-ing them completely couldn't lead to a panic.

[colin-axner]

It should be safe to remove. But if you want to be ultra safe, we can change the ValidateBasic of both proposal types to return an error. This is at least the first step in preventing users from submitting legacy proposal types. Then after some time, we could remove the type and be certain there are no in-flight proposals

[colin-axner]

I'm in favour of pure removal. I think the additional defensive step to prevent submission is unnecessary in my opinion. We could backport the validate basic error to v8, but I don't see a reason in keeping the types around in v9 to ensure there are never in-flight proposals