feat(rust/vote-tx-v2): Public vote tx v2 CBOR decoding/encoding implementation

[Mr-Leshiy]

Description

• Updated cddl specs for the v2 vote transactions, made voter-data type generic, the same as choice, proof, and prop-id.
• Made GeneralizedTx structure generic according to the original cddl spec.
• Refactored GeneralizedTx code structured it across different Rust modules.
• Added GeneralizedTxBuilder structure.
• Added missing validation during the decoding GeneralizedTx.
• Added new PublicTx structure with the corresponding Choice, Proof and PropId types definitions according to the cddl spec.
• Implemented CBOR encoding/decoding functionality for PublicTx and all underlying types.

Related Issue(s)

#84

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 228/228}$ | ${\color{red}Fail: 0/228}$ |

[minikin]

The only suggestion I have. To consider creating a module for vote-related types:

pub mod vote {
    pub trait CborSerializable: for<'a> Cbor<'a> {}
    impl<T: for<'a> Cbor<'a>> CborSerializable for T {}
    
    pub type VoteChoice = Box<dyn CborSerializable>;
    pub type VoteProof = Box<dyn CborSerializable>;
    pub type ProposalId = Box<dyn CborSerializable>;
    ...
    ...
    ...
}

[cong-or]

where is the 3 defined?

[Mr-Leshiy]

It is defined from the cddl spec

vote<choice-t, proof-t, prop-id-t>  = [
    choices<choice-t>,
    proof<proof-t>,
    prop-id<prop-id-t>,
]

so basically, vote type here a cbor encoded array with the 3 field in it.
Also I've discussed with @stevenj that we should allow only definite sized arrays and maps in such cases (because cbor also allows to have indefinite size arrays and maps and cddl does not specify it). I will put a note into our spec about it.

[Mr-Leshiy]

@cong-or so probably we will also need to revisit ledger encoding implementation to double check that it encodes as a finite cbor arrays and cbor maps for the types, but its not urgent and for now its totally ok if its not strictly verifies it.

[cong-or]

lgtm