chore(all): use a builder pattern for safe serialization API

[nsarlin-zama]

closes: https://github.com/zama-ai/tfhe-rs-internal/issues/646

PR content/description

The goal of this PR is to simplify the safe_serialization API. With the introduction of data versioning, there are many different serialization possibilities:

• safe or not,
• conformant or not (only for deserialization),
• versioned or not

This can be difficult for us to maintain and confusing to the user since the function they should use by default have the most complicated names (safe_deserialize_conformant_versioned). The idea is to introduce a simple builder pattern to configure the serialization, with the safest defaults and with a possibility to disable functionalities for advanced users.

This PR introduces 2 objects, SerializationConfig and DeserializationConfig. The idea for serialization is to create this object, eventually modify it to disable some functionalities, and serialize an object with the serialize_into method:

• default config (safe + conformance + versioning):

// Serialization is "safe" by default, so we have to give the max size to the config
SerializationConfig::new(1 << 20).serialize_into(&ct, &mut buffer).unwrap();
    

// Deserialization is also "conformant" by default, so we also have to give some conformance parameters
DeserializationConfig::new(1 << 20)
    .deserialize_from::<FheUint8>(buffer.as_slice(), &conformance_params)
    .unwrap();

• no versioning:

// We use the `new` constructor and disable the functionality
SerializationConfig::new(1 << 20).disable_versioning().serialize_into(&ct, &mut buffer).unwrap();
    
// No need to configure that the data is not versioned, this is detected during deserialization
DeserializationConfig::new(1 << 20)
    .deserialize_from::<FheUint8>(buffer.as_slice())
    .unwrap();

• no conformance:

SerializationConfig::new(1 << 20).serialize_into(&ct, &mut buffer).unwrap();
    
// Here we use the `new_without_conformance` so we don't have to give conformance params that won't be used
DeserializationConfig::new(1 << 20)
    .disable_conformance()
    .deserialize_from::<FheUint8>(buffer.as_slice())
    .unwrap();

The safe_serialize/safe_serialize have been kept as defaults for users that don't need customization. They include versioning.

Other changes:

• The versioning state (enabled or not) is encoded in the serialized data and is detected automatically during deserialization. This mean that DeserializationConfig::new(...).deserialize_from(...) handles both versioned and unversioned data.
• If the data is unversioned, the tfhe-rs version is stored in the binary file, and we raise an error if the version is different than the current one (this check can be disabled if the user is sure that the types are compatible).
• In the C API, the only safe_serialization method is versioned. There are also serialize/deserialize (without safe) that are only wrappers around serde.
• In the JS API the only safe_serialization method is versioned.

Check-list:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features) -> update serialization doc
• Relevant issues are marked as resolved/closed, related issues are linked in the description
• Check for breaking changes (including serialization changes) and add them to commit message following the conventional commit specification

[mayeul-zama]

Thanks!

[tmontaigu]

Do we think having a default value for the size_limit could be good, and maybe have an impl Default for SerializationConfig that uses that default size_limit ?

[nsarlin-zama]

What would be a good default value ? We don't know the kind of device where this will run nor the concrete type that is deserialized

[tmontaigu]

In all our example we use 1 << 20, which is roughly 1GB, and I bet most users are just going to copy paste that

[nsarlin-zama]

Are you ok if I add this as an issue to not rush this before release ?

[IceTDrinker]

1<<20 = 1 MB IIRC

1 << 30 = 1GB