refactor: decode ContentValue only with known ContentKey

[morph-dev]

What was wrong?

When decoding *ContentValue, we try decoding all possible types until one succeed. This is dangerous as wrong type could succeed first (when two values have identical encoding). The correct approach is to decode content values in the presence of the content key, which should be known.

This happens for some types of content values on the state network.

This problem doesn't exist for the content keys, as they have unique prefix.

How was it fixed?

Changed ContentValue::decode and ContentValue::from_hex functions to require content key.

This broke the deserialization of the content values (which makes sense as they can't be deserialized correctly without knowledge of the content key), which resulted that we can't use existing *ContentValue types in json apis.

To solve this, I introduced RawContentValue type that is basically alloy_primitives::Bytes (that serialize/deserialize to/from "0x..." strings).

Future work

I tried to keep this PR as small as possible (it's already big enough), but I think that we should use alloy_primitives::Bytes everywhere where we currently use Vec<u8> to represent content key/value. Reason is that copy is much cheaper and it (de)serializes into hex string. Also, having concrete type name instead of Vec<u8>, makes code more readable.

Created #1404 to track this.

To-Do

• Clean up commit history and use conventional commits.

[ogenev]

Nothing stands out to me 💯 . This PR is a great improvement and paying some of the tech debts :).

[KolbyML]

looks good