fix: remove specific encoding constants related to serialization

[wyfo]

fixes #1507

[github-actions]

PR missing one of the required labels: {'documentation', 'bug', 'dependencies', 'internal', 'new feature', 'breaking-change', 'enhancement'}

[milyin]

Looks good for me. I did similar PR (#1512), I think they can be combined in the following way:

• explicitly say that ZENOH_BYTES and ZENOH_STRING corresponds to to_bytes() and try_to_string() methods
• reference zenoh-ext in ZENOH_SERIALIZATION
• remove ZENOH_ERROR - it doesn't make sense at all. The ReplyError type contains encoding field whcih is set to data packet, this leaves no place to special encoding for ReplyError
• (questionable) avoid full renumbering of encoding ids and keep the range 0..15 for possible future ZENOH_* encodings

[wyfo]

explicitly say that ZENOH_BYTES and ZENOH_STRING corresponds to to_bytes() and try_to_string() methods

Encoding is neither mandatory nor automatic, so I don't see why we would assign an encoding to a method of ZBytes. You can encode a string without specifying an encoding, and use try_to_string on the other side.
Also, if you encode some JSON data, you will use either to_bytes or try_to_string to retrieve the bytes and read your JSON, so the methods are not really related to the encoding.

reference zenoh-ext in ZENOH_SERIALIZATION
Will do

remove ZENOH_ERROR - it doesn't make sense at all. The ReplyError type contains encoding field whcih is set to data packet, this leaves no place to special encoding for ReplyError

If you say so

(questionable) avoid full renumbering of encoding ids and keep the range 0..15 for possible future ZENOH_* encodings

Questionable indeed. Honestly, I want to remove all ZENOH_XXX encoding, so I don't want to support that idea.

[milyin]

explicitly say that ZENOH_BYTES and ZENOH_STRING corresponds to to_bytes() and try_to_string() methods

Encoding is neither mandatory nor automatic, so I don't see why we would assign an encoding to a method of ZBytes. You can encode a string without specifying an encoding, and use try_to_string on the other side. Also, if you encode some JSON data, you will use either to_bytes or try_to_string to retrieve the bytes and read your JSON, so the methods are not really related to the encoding.

The ZENOH_ encodings existed for a long time and I see no reason to remove them now. They makes sense in zenoh infrastructure and thay means that data can be interpleted using zenoh's tools. Now it can be some unknown blob "ZENOH_BYTES", an UTF-8 string "ZENOH_STRING" and zenoh serialized data "ZENOH_SERIALIZED". So it makes sense to keep them and reference to corresponding zenoh's functions in documentation

(questionable) avoid full renumbering of encoding ids and keep the range 0..15 for possible future ZENOH_* encodings

Questionable indeed. Honestly, I want to remove all ZENOH_XXX encoding, so I don't want to support that idea.

I'm against removing ZENOH_XXX and if we are keeping them, it makes sense to keep range for them

Also no renumbering - less potential data conversion problems

[milyin]

@wyfo : discussed it on morning meeting with @kydos . We need to keep ZENOH_ prefixes. I'd also would recommend to keep the gap 0..15 for ZENOH_ prefixes - this gap occured naturally and it can be useful in the future

[milyin]

replaced with #1512