serde: add default deserializers implementations

[hackaugusto]

The Deserializer trait does not have an associated type, all methods return Self. That means it is not possible to have a blanket implementation for slices &[T], because the signature is required to be fn read_from<R: ByteReader>(source: &mut R) -> Result<&[T], DeserializationError>;. I can't add a associated type without making a breaking change because default associated types are unstable https://github.com/rust-lang/rfcs/blob/master/text/2532-associated-type-defaults.md. I also can't define a blanket implementation for Vec<T> because the default serializer does not include the length of the vector.

edit: also note:

• the serializer doesn't return errors, if one decides to encode an usize into u8 there is nothing to do besides panicking, this could be an attack vector.
• the write_batch_into is the same as the vec implementation, should probably be removed since it doesn't have a clear receiver and there is equivalent functionality

[hackaugusto]

I added a blanket implementation for impl<T, C> Serializable for [T; C]. Together with the existing blanked implementation for Vec<T>, &Vec<T>, and &[T], it made these 3 implementations obsolete.

[irakliyk]

Thank you! Looks good! I left a few small comments inline.

[irakliyk]

This deviates somewhat from how we serialize lists in that we try not to make assumptions data types used to serialize the number of elements. I think we can leave it up to the callers to figure out how exactly they want to serialize a given string.

[hackaugusto]

I don't understand the problem. You don't want these implementations? You don't want to include the string length?

[hackaugusto]

I guess the issue is with the use of as_bytes? You don't want to encode the data as utf8?

The biggest issue here is that the user can not implement this trait, because of the orphan rules. So here we either have to make the choice or not give an implementation to the user.

When the user is writing their own Serializable, they can also deviate from this by just not calling it.

[irakliyk]

I would prefer to remove these implementations as serializing strings without length is probably not a good idea, and serializing them with length is not consistent with the overall approach (e.g., different from how we serialize slices, vectors etc.).

I don't think this affects the usability too much as the user can serialize strings manually pretty easily - e.g.,:

let x = "hello world".to_string();

target.write_u64(x.len() as u64);
target.write_bytes(x.as_bytes());

On the deserialization front, I think we can improve the ergonomics by adding read_string() method to ByteReader interface. It could look something like:

fn read_string(&mut self, len: usize) -> Result<String, DeserializationError> {
    let data = source.read_vec(len)?;
    String::from_utf8(data).map_err(|err| DeserializationError::InvalidValue(format!("{err}")))
}

[hackaugusto]

I would prefer to remove these implementations as serializing strings without length is probably not a good idea, and serializing them with length is not consistent with the overall approach (e.g., different from how we serialize slices, vectors etc.).

The question is, does it make sense to serialize slices and vectors without length too? And if this is done for consistency sake, why can't the String be serialized without the length too?

I don't think this affects the usability too much as the user can serialize strings manually pretty easily - e.g.,:

Your call

On the deserialization front, I think we can improve the ergonomics by adding read_string() method to ByteReader interface. It could look something like:

This can be done in another PR.

Removed the default implementation

[irakliyk]

Similar comment to one of the previous comments re strings: I'd rather not make opinionated choices about which data type to use for serializing string lengths.

[irakliyk]

It is a bit unfortunate that we have to allocate a vector here to deserialize the data - but I wonder if the compiler is smart enough to figure out that this is not needed.

[irakliyk]

Looks good! Thank you!