Switch const serialize to use CBOR

[ealmloff]

Currently const serialize uses a bespoke endianness erased packed format which is very simple to support, but is not self describing. This makes any change to the layout of the data including adding fields or adding enum variants a breaking change.

This PR switches to CBOR which is both a relatively simple format to support and is self describing.

While this PR should make breaking changes to manganis more forgiving in the future, the change in format itself is breaking because old version of the CLI don't know how to deserialize the new cbor format

TODO:

• [x] Numbers
• [x] Arrays
• [x] Structs
• [x] Enums
• [x] Bytes
• [x] Strings
• [x] Documentation + final review

Closes #4863

[jkelleyrtp]

I wonder if we might be able to add a header with a magic number to identify different versions from each other, letting us support the old format and the new cbor format both in 0.7

[ealmloff]

I wonder if we might be able to add a header with a magic number to identify different versions from each other, letting us support the old format and the new cbor format both in 0.7

Supporting the old version of assets in the new version of the CLI is fairly easy. The difficult case is supporting the new version of assets in the old version of the CLI.

If you run cargo update dioxus will be updated and the new version of assets will be used, but dx will not be updated and will fail to deserialize the new assets

[jkelleyrtp]

Supporting the old version of assets in the new version of the CLI is fairly easy. The difficult case is supporting the new version of assets in the old version of the CLI.

We could push an update that reads the current dx version in dioxus and then throws an error if dx is too old for the current dioxus. I think we might already throw an warning in the CLI, but we could make this release a hard error.

[ealmloff]

We could, wasm-bindgen does something similar requiring a matching version of the wasm-bindgen-cli and wasm-bindgen itself. That has made it difficult to work with wasm bindgen programmatically in our CLI. We now bundle a wasm-bindgen version management system within the CLI

I imagine consumers of dx tools will end up needing to do something similar. We could include the version management system within the CLI itself

[ealmloff]

The CLI now decodes both the 0.7.0-0.7.1 version of assets (under the __MANGANIS__ symbol prefix) and the new more stable serialization (under the __ASSETS__ symbol prefix)

While this is still breaking for const-serialize itself, it shouldn't be breaking for manganis or dioxus since neither of those crates export const serialize types outside of unstable macro helpers

[jkelleyrtp]

The CLI now decodes both the 0.7.0-0.7.1 version of assets (under the __MANGANIS__ symbol prefix) and the new more stable serialization (under the __ASSETS__ symbol prefix)

While this is still breaking for const-serialize itself, it shouldn't be breaking for manganis or dioxus since neither of those crates export const serialize types outside of unstable macro helpers

Exciting! Will give it a test drive. Very keen to start adding more variants for things like serverfn metadata and it will be useful to do this without requiring a full version bump

[ealmloff]

It required a larger change than I was expecting, but the solution we talked about yesterday does work for backwards compatibility. It now bundles under the old MANGNIS symbol name as well as the new name which works when you update dioxus to this branch but still use the CLI from the 0.7.1 release