fix(rust/catalyst-types): Convert UUID types to cbor

[saibatizoku]

Description

Add conversion from UUID types into CBOR values.

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: 294/294}$ | ${\color{red}Fail: 0/294}$ |

[stevenj]

I am not loving the existing and new coset types in the UUID types.
The reason being is that coset uses the ciborium library under the hood. This means we end up with two different ways of encoding the exactly same binary stream. Its a maintenance issue.

We settled a while ago on using minicbor for our go-to cbor encode/decode library.
I don't think we should be bringing in cborium or any other cbor encoder into our common libraries.

Its also unnecessary. minicbor can serialize/deserialize from bytes (Vec).
If we are forced to use ciborium then it should be 100% constrained to the crate that brings that requirement in (another topic).
We should be able to use the minicbor encode/decode functions for these types when converting too-from cbor, and just convert the upper type. All this requires is the ability to convert between a (in this case) coset value and vec which it should be under the hood anyway.

I want us to remove coset from the dependencies of this crate, use minicbor only for encoding/decoding to-from vec and the uuid types, so that there is a single source of truth for cbor encoding for these types. If the library we are using does not support minicbor then we should either:

1. Use a library that does.
2. (if 1 above can not work) Wrap the minicbor encode/decode in the crate which needs the non minicbor encoder and not in the types themselves.

[github-actions]

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

[github-actions]

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

[stevenj]

For generality, encoding with a Tag should be optional.
Suggest adding a context tag: bool.

• true = encode with a tag
• false = encode without a tag.

[stevenj]

For generality, there are three possible options one would want on a decode:

1. MUST have a TAG
2. MUST not have a TAG
3. Optionally has a TAG.

Suggest adding a tagged: Option<bool> as the context.

• None = Optionally has a Tag
• Some(true) = Must have a Tag
• Some(false) = Must NOT have a Tag

[github-actions]

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

[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}$ |

[github-actions]

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

[github-actions]

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

[github-actions]

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

[github-actions]

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

[Mr-Leshiy]

Despite one comment LGTM

[github-actions]

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

[stevenj]

LGTM

[stevenj]

LGTM