feat: Add CLI for new gov proposal

[amaury1093]

Description

Closes: #10952

Depends on : #10490 for proposal metadata

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[amaury1093]

LMK what you think about this JSON format for submitting a proposal.

[cmwaters]

Yeah I think that's preferable

[cmwaters]

Is it necessary to support backwards compatibility via the CLI? We're changing the command name anyway so it already breaks users scripts. I also think most people submit proposals via JSON anyway so I don't think we need to keep around all the legacy flags

[cmwaters]

Yeah I think that's preferable

[amaury1093]

Is it necessary to support backwards compatibility via the CLI?

I have a slight preference for keeping submit-legacy-proposal. The current PR breaks user scripts as you say, but a s/submit-proposal/submit-legacy-proposal will fix those scripts.

If we only allowed the new Msg-based proposals, there will be some non-trivial changes to make for CLI users (aka converting their proposal JSONs or flags)

[cmwaters]

Yeah you're right that they're non-trivial changes but my theory is that dev ops people, like all good programmers are inherently lazy, and I doubt any of them will change their scripts until v0.47 when we finally remove support and it breaks them.

[amaury1093]

I agree with that observation. However, I'd argue that telling them the cmd is deprecated and will be removed in the next release, is a better UX than forcing them to do changes ASAP.

I also think we need a CLI (or some other tooling) to create proposal JSONs. Currently the only way is to write this JSON #11013 (comment) manually, which is error prone.

I wonder if @aaronc of @blushi have opinions here, maybe we should align this with group's create-proposal.

[cmwaters]

Aside from our decision around how breaking we want this to be, the changes here LGTM

[blushi]

I wonder if @aaronc of @blushi have opinions here, maybe we should align this with group's create-proposal.

I would agree with this.

[amaury1093]

I created #11070.

Anyways, I would prefer to tackle 11070 in a follow-up: this PR adds CLI functionality and tests, and #11070 deals with UX (and might also need to change proto Msg names). LMK if that works.

[blushi]

I created #11070.

Anyways, I would prefer to tackle 11070 in a follow-up: this PR adds CLI functionality and tests, and #11070 deals with UX (and might also need to change proto Msg names). LMK if that works.

Sounds good to me!

[atheeshp]

lgtm