[FEATURE] - Extend commands to use governance action identifiers from CIP129

[CarlosLopezDeLara]

What

To be fully compatible with cip129 we need to extended the following commands so that users can provide as parameters the governance actions identifiers as defined in CIP129:

• query proposals
• governance vote create

Details

• Expand query proposals so that it takes cip129 governance action identifiers (hex and bech32)

 ( --all-proposals
| (--governance-action-tx-id TXID
 --governance-action-index WORD16)
| governance-action-identifier <HEX or BECH32>                                               
)

• Expand governance vote create so that it takes cip129 governance action identifiers (hex and bech32)

(
(--governance-action-tx-id TXID
 --governance-action-index WORD16)
| governance-action-identifier <HEX or BECH32>                
)

For example:
https://cardanoscan.io/govAction/gov_action12meeq4r43udremwpm6fzt4nt7fctvt0ah7798x036m2r4nhlccmqqhmr9wx

TxId: 56f39054758f1a3cedc1de9225d66bf270b62dfdbfbc5399f1d6d43aceffc636
TxIx: 0
CIP129 HEX: 56f39054758f1a3cedc1de9225d66bf270b62dfdbfbc5399f1d6d43aceffc63600
CIP129 BECH32: gov_action12meeq4r43udremwpm6fzt4nt7fctvt0ah7798x036m2r4nhlccmqqhmr9wx

Why

Necessary to fully support CIP129, most explorers and govtools use CIP129 to identify GOVERNANCE ACTIONS, so it makes sense for the CLI to use the same terminology used in those places.

Personas

• SPOs
• dApp Devs
• Exchanges
• Wallets
• 3rd party tools
• ADA holders
• DReps
• CC members

Definition of Done (DoD)

• Acceptance Criteria + User Stories & DoD created and singed-off (by PO, dev & test owners)
• Builds successfully on CI
• Code & Test review (as per Acceptance Criteria)
• There is documentation and/or examples for the new functionality (usage/response)
• Log/record changes on Vnext (or similar depending on what we adopt)
• Ticket number(s) included in PR description
• All Acceptance Criteria met and covered by dev/unit/property/integration tests
• System/E2E automated tests + System Test Engineer Owner Sign-off

NOTE: Ideally, we should merge only fully implemented and tested features into the master branch.
So all the above steps are required for the PR to be merged.
In order to avoid the PRs becoming stale and requiring to be rebased on master, these can be merged
after a reasonable time (current agreement is 3 days) if the System Test Engineer Owner's sign-off
was not provided (last step in the DoD).

IMPORTANT: Any deviation from the plan should be discussed and agreed as a comment in the Feature file.

Sign-off

• Product Owner
• Dev Owner
• System Test Engineer Owner

Related PRs

1. PR # here

Acceptance Criteria

Acceptance Criteria & User Stories define here (or in a separate file (linked here) for a big feature)

Example - IntersectMBO/cardano-node#4453

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.