Sample rework

[milyin]

After latest discussions with @Mallets, @DenisBiryukov91 the following approach to Sample structure was made:

• For all languages (in so called "core" API) Sample is a data structure received from queryable or publisher, i.e. input parameter for callbacks of get and subscriber.

• Sample is Zenoh internal structure, it's actual representation is hidden from user. Sample data is accessed by getter methods. These getters are part of "core" API.

• Sample received by get or subscriber may be owned by user. Use can store it in memory and modify it using setters. This behavior is not a part of core API, i.e. some bindings may provide only R/O access to received sample.

• Sample structure can be

  • sent by publisher's "write" method (maybe it's worth to rename it to "send_sample" ?)
  • sent from queriable with "reply_sample" method.

  These features are not part of core API and user is should not be encouraged to use it. But these features are useful for some storages/caches where we resending the same sample which we received. So maybe it makes sense to include them to stable Rust API. For API completeness user is allowed to create the new sample.

I.e. in other words, we have API separated to two parts:

Core API

This is API obligatory for all language bindings.

Operations "put", "delete", "reply" are builders which technically builds the sample from pieces and sends it, but they doesn't give user access to this sample. Example:

publisher
   .put("payload")
   .with_attachment(attachment)
   .with_priority(High)
   .sync();

Operations 'get', 'subscribe' receives 'Sample' - some entity with set of accessor methods, i.e. get_payload(), get_attachment(), etc.

Optional API

I don't know how to better name it. "Extended" API is not good because it reminds about zenoh-ext, which is unrelated to this case. "Rust" API is wrong too: many of this functionality is provided not in Rust only and some functionality may exist in other languages, but not in Rust - like synchronization primitives. "Expanded" API maybe?

The idea of this "optional" API is that this API is not obligatory for all bindings, but if it's provided, it must be coherent in all bindings.

In Rust API (and supposedly in C and C++ APIs) the sample can be owned by user. This allows him to receive sample, make modification to it with setter methods (like "ensure_timestamp") and then send this sample. The storages will use this feature for example.

The user can also create sample (with constructor interface similar to "put", "delete"), depending on the language, i.e. builders for Rust, z_create_sample in C with structure for options.

[milyin]

This work is related to issues below, which have to be resolved accordingly:
#650 #810 #803
eclipse-zenoh/zenoh-c#251

[milyin]

Done in #858