ROS1 bridge for Zenoh

[Mallets]

Discussed in #59

^{Originally posted by yellowhatter November 2, 2022}

There is a task to support ROS1 in zenoh.

I have a plan to implement zenoh plugin working with ROS1 in the same manner as it was made in zenoh-dds plugin. Of course the details of realization are different, but from the outside the plugins would be similar. The plugin is in Rust, working as client from ROS1 side. I'm also aware of the details (ros1-ros2 message compatibility, some optimizations etc) and targeting to build a complete solution which will be able to provide ROS1<->ROS1 and ROS1<->ROS2 communication.

Why not replacing Master?
Because ROS1 Master is not involved in data exchange process, ROS1 peers do establish direct data connections (rostcp or rosudp protocol) between each other while Master works as some kind of Nameservice (xml-based protocol) providing peers with information on topics and info needed to establish direct data connection with peer ( == subscribe for the topic). For Zenoh there is no use of reimplementing Master (as it won't give us optimizations on data transfer) - it is enough to create a special client based on ROS1 Client Library.
ROS1 Client Library has enough functionality (it implements rostcp/rosudp for data exchange and also xml-based protocol for Master) and there is no need to reimplement and support ROS1 protocol stack on our side - we could just use this library to do the trick.

Some optimizations could be made
There are currently some ideas on optimizations:

1. Convert ROSx to ROSy data on receipt side as the default behavior. When publishing data, the ROSx Publisher doesn't know whether it's data will be consumed by somebody expecting ROSy or not, thus there is no need to waste CPU cycles on converting it on publisher's side. ROSx publisher will simply publish the data marking it has "ROSx" format, and the subscriber could perform conversion to ROSy if needed.
2. Select publishing format by config. For the previous case, if there are some special needs, the publisher could be forced to convert the data to ROSy format by configuration. That could be useful in many cases (if many subscribers expect ROSy format or there is no CPU on subscriber's side to perform the convertion, etc).
3. Subscribe on ROS1-Zenoh layer only on needed topics. The topic list to subscribe to could be determined automatically.