feat: support for custom (de)serializer

[J-Loudet]

This commit introduces the following changes to Zenoh-Flow:

1. types used within a Zenoh-Flow application do not have to implement the
   (cumbersome) ZFData trait; instead,
2. the types used must be Send + Sync + 'static,
3. an Output must know how to serialize the provided type T and, respectively,
   an Input must know how to deserialize bytes into T.

With these changes, any SerDe compatible data serialization format is supported
as well as, for instance, ProtoBuf.

In terms of API, the major difference is how the Input and Output are obtained:

input: inputs
    .take("in", |bytes| todo!("Provide your deserializer here"))
    .expect("No input called 'in' found"),

output: outputs
    .take("out", |data| todo!("Provide your serializer here"))
    .expect("No output called 'out' found"),

[gabrik]

First pass, overall LGTM, a few comments, and the Debug is important for us to be used in logging, otherwise, we may never be able to understand what it is going on.

I need to give a more deep pass on it,

[gabrik]

I'm thinking if Input and Output shouldn't become traits.
Let me explain we could have a builder pattern for getting inputs and outputs (in the future we could add things like dropping policies, etc.), and based on passing or not the se/deserializer you get something that implements the trait with functions like recv<T> where T is typed if you passed the se/deserializer or Arc<Vec<u8>> if not.

Not really sure how this would translate to code.

[J-Loudet]

I'm thinking if Input and Output shouldn't become traits. Let me explain we could have a builder pattern for getting inputs and outputs (in the future we could add things like dropping policies, etc.), and based on passing or not the se/deserializer you get something that implements the trait with functions like recv<T> where T is typed if you passed the se/deserializer or Arc<Vec<u8>> if not.

Not really sure how this would translate to code.

Maybe a trait is not needed, the builder pattern could be enough: take("port_id") would create an InputRaw builder, a following call with_deserializer(…) would turn in into a typed Input. Same logic for the Output.

That's what you had in mind?

[gabrik]

Maybe a trait is not needed, the builder pattern could be enough: take("port_id") would create an InputRaw builder, a
following call with_deserializer(…) would turn in into a typed Input. Same logic for the Output.
That's what you had in mind?

Yep, just because of the take and take_raw that could be simplified, using a single take and the builder pattern, I think what you propose should work fine.

[gabrik]

LGTM, modulo the discussion on the builder for the inputs/outputs.

[gabrik]

This depends on: #158