Issue Credential V2.0 message structures

[gmulhearn-anonyome]

NOTE: I've gone with v2.0 (as opposed to v2.1 & v2.2), this is primarily because it seems to be what others (aca-py & AFJ) are targeting and expect. similarly, V2.0 is what AIP2.0 lists as it's requirement: https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0302-aries-interop-profile/README.md#base-requirements

• Rename all existing issue-credential message types to have a V1 suffix
• Put v1 and v2 messages in different structures

Also note, I'm consuming these messages in the Issuer and Holder V2 impl: #987

Also also note, have tested holderv2 against aca-py for issue-credential-v2, which should confirm that the message structures are interoperable with acapy

[codecov-commenter]

Codecov Report

Merging #990 (21b2796) into main (ecc2047) will decrease coverage by 0.19%.
The diff coverage is 18.69%.

@@            Coverage Diff             @@
##             main     #990      +/-   ##
==========================================
- Coverage   30.02%   29.83%   -0.19%     
==========================================
  Files         415      424       +9     
  Lines       26916    27082     +166     
  Branches     5243     5290      +47     
==========================================
  Hits         8081     8081              
- Misses      16639    16802     +163     
- Partials     2196     2199       +3     

Flag	Coverage Δ
unittests-aries-vcx	29.83% <18.69%> (-0.19%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...protocols/issuance/holder/states/offer_received.rs	17.85% <100.00%> (ø)
...c/protocols/issuance/holder/states/proposal_set.rs	62.50% <100.00%> (ø)
...rc/protocols/issuance/holder/states/request_set.rs	77.27% <100.00%> (ø)
...protocols/issuance/issuer/states/credential_set.rs	30.00% <100.00%> (ø)
.../src/protocols/issuance/issuer/states/offer_set.rs	93.10% <100.00%> (ø)
...tocols/issuance/issuer/states/proposal_received.rs	100.00% <100.00%> (ø)
...ocols/issuance/issuer/states/requested_received.rs	37.50% <100.00%> (ø)
aries_vcx/tests/utils/scenarios/data.rs	96.49% <100.00%> (ø)
...lds/protocols/cred_issuance/v1/issue_credential.rs	25.00% <ø> (ø)
...s/protocols/cred_issuance/v1/request_credential.rs	28.57% <ø> (ø)
... and 31 more

... and 1 file with indirect coverage changes

[bobozaur]

Looks good overall.

The only thing I'd change would be renaming/compartmentalizing stuff related to the V1 protocol version a bit better, since now there's V2 stuff laying around.

[bobozaur]

@gmulhearn-anonyome I'll try to put together some guidelines for the message crate in a README file to maybe clarify how things get pieced together. But if you have any specific questions before then, feel free to ask here.

[gmulhearn-anonyome]

@bobozaur thanks for the feedback. let me know what you think about this latest revision

[bobozaur]

Almost there.

The only nitpick I have is about the conversions that arise from introducing the CredentialIssuance wrapper enum (since there are two versions now).

There are all these intermediate enums throughout the crate which are really there simply for composition purposes. You should rarely have to work with the CredentialIssuanceV1 enum directly.

The actual messages all have implementations of From (through the transit_to_aries_msg macro) to convert them to an AriesMessage directly specifically to avoid the need to deal with all the nested enums.

[bobozaur]

LGTM. If CI passes then it's all good on my end.