Add serde feature to our stack

[Neotamandua]

Summary

Introduce a serde feature to execution-core that allows serde Serialize & Deserialize to be used on structs that are also used on the integration side (for example, all event structs from the genesis contracts).

Edit:
We want to implement the serde feature on every type where rkyv is also implemented for.

The decision has been made to use the following encodings:

• Use base58 as the encoding for any type related to keys. (This includes PublicKey, Address, Signature, SecretKey, etc.)
• use hex/base16 for other types unrelated to keys that have meaning in our stack
• use base64 for any opaque type that cannot be represented in any useful way (e.g. unknown payloads, proofs)

Additional context

Relevant issues:

• Add Serde Feature jubjub#143
• Add serde support bls12_381-bls#21
• Add serde support jubjub-schnorr#29
• Add Serde Feature phoenix#258
• Add Serde Feature piecrust#414

[d-sonuga]

The types used by event structs, along with relevant subfields defined in other dusk crates, are

• ContractId (piecrust_uplink)
• StealthAddress (phoenix_core), needed in WithdrawReceiver for ConvertEvent and WithdrawEvent
  • JubJubExtended (alias for ExtendedPoint in dusk-jubjub) - Fq (alias for Scalar in dusk-bls12_381)
  • NotePublicKey (PublicKey in jubjub-schnorr) - JubJubExtended
• Scalar in dusk-bls12_381 is also needed in PhoenixTransactionEvent
• Note (phoenix_core), needed in PhoenixTransactionEvent
  • JubJubAffine (alias for AffinePoint in dusk-jubjub) - Fq (alias for Scalar in dusk-bls12_381)
  • Sender - JubJubAffine
• PublicKey (bls12_381-bls) used in SlashEvent, ConvertEvent, DepositEvent, ContractToAccountEvent, StakeKeys which is used in StakeEvent and WithdrawReceiver which is used in WithdrawEvent.

Following from this, serde Serialize and Deserialize implementations will be needed in:

• Scalar in dusk-bls12_381
• Note, Sender and StealthAddress in phoenix-core
• AffinePoint and ExtendedPoint in dusk-jubjub
• PublicKey in bls12_381-bls
• PublicKey in jubjub-schnorr
• ContractId in piecrust-uplink

[ZER0]

One additional point to consider: I’m not sure how you’re currently handling the serialization of u64, but it’s important to remember that these are bigint not number, which JSON does not natively support.
Most likely, they will be converted to strings.
However, for an agnostic client, there’s no inherent difference between a regular string and a string containing only numeric characters, so they cannot automatically be decoded into bigint.

To address this, the web app team has adopted a specific approach to serializing bigint values. They append an n at the end of the string representation (e.g., "10234n"), enabling automatic conversion back into bigint.

If feasible, I’d like our serde_json serialization to follow the same pattern.