Add ROS test with CI.

[evshary]

In our current CI, there is no test on the transformation between ROS and Zenoh.
This makes our development less efficient and makes it impossible to ensure quality when it comes to more and more combinations of tests.
For example, how to make sure our tests can work in both Humble and Jazzy? When it comes to different environmental variables, how to know it won't break the backward compatibility?
The PR is a trial to see how it works by using r2r.

[github-actions]

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

[evshary]

The failure is related to this #351

[evshary]

@JEnoch I can test pub/sub between ROS and Zenoh now. Tested both in Humble and Jazzy.
Please let me know if you have any comments.
Also, do you want it merged first, or can I add the service and action test in the same PR?

[JEnoch]

I think the setting of RMW_IMPLEMENTATION=rmw_cyclonedds_cpp should be hard-coded in the tests. Otherwise, r2r picks the default RMW which won't fully work with the bridge if not CycloneDDS.

[JEnoch]

Also, do you want it merged first, or can I add the service and action test in the same PR?

I think it's fine to have just pub/sub in a first PR, and to add others later.

But as most of users are using the plugin to bridge 2 distinct DDS domains (different hosts without DDS comms or different domains), I would also like to see such tests.
Do you think it's feasible in the same process ? (2 plugins with different configs, and 2 Nodes using different domains)

[evshary]

Do you think it's feasible in the same process ? (2 plugins with different configs, and 2 Nodes using different domains)

I don't think so. I looked into the ROS code. Indeed, we can use rclcpp::init(argc, argv, options) and put domain ID inside options, but the setting is global, which means we can't have two different domain ID in the same process. Not to mention, r2r doesn't provide such API to do the configuration.
I think a better way here is to put these kinds of tests into the zenoh-test, which is easier to run multiple processes. We've already have something similar in zenoh-bridge-dds. We can do the same thing for ros2dds.