feat(rust/signed-doc): Add deserializer for Catalyst Signed Documents

[saibatizoku]

Description

Thanks for contributing to the project!
Please fill out this template to help us review your changes.

Related Issue(s)

Closes input-output-hk/catalyst-voices#1364

Description of Changes

Provide a clear and concise description of what the pull request changes.

Breaking Changes

Describe any breaking changes and the impact.

Screenshots

If applicable, add screenshots to help explain your changes.

Related Pull Requests

If applicable, list any related pull requests.

e.g., #123, #456

Please confirm the following checks

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream module

[github-actions]

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

[stevenj]

I see we are using coset as a library here.
I am not asking that we change this as it would be too much work and we do not have the time, but the problem is, it relies on cborium which we decided earlier that we would not use.
As this crate now has a hard dependency on cborium, any and all decoding issues caused by that need to be 100% constrained to this crate.

Ultimately I would like us to not have any cborium dependency anywhere in our tree, which means we need an issue to stop using coset and either write our own cose encode/decode using minicbor or find another library. I don't think encoding/deciding cose is very challenging, especially as we only have a requirement for COSE_SIGN and none of the other COSE formats.

In future if any crate brings in a CBOR dependency other than minicbor we need to have a discussion before brining it in, as it creates a maintenance issue having multiple ways to encode/decode the same data to/from ultimately the exact same binary stream.

However this does mean that no types we have defined elsewhere can have either a cborium or coset dependency. That needs to be 100% constrained to this crate.

Also note for clarity, we should NOT add Type Encoding here to cbor for any type, we should be encdoing/decoding to/from vec and using minicbor for that, and then just using the appropriate higher level type.
I do not want to see multiple ways to encode/decode any type to the same binary formats because of differing dependent library choices made by upstream crates.

[github-actions]

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

[Mr-Leshiy]

LGTM

[github-actions]

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

[github-actions]

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