dds-stream-sensor-bridge and on-demand streaming, with very basic ROS2 compatibility

[maloel]

The goal was:

• Have ROS see our streams
• Have rs-dds-server automatically start streaming when a stream is opened, while allowing maximum flexibility when then trying to stream other streams
• Keep the viewer working as before

Currently:

• ROS sees our streams, but can only understand the format of the RGB stream

Tracked on [LRS-385]

[OhadMeir]

I still don't completely understand the bridge, and lots of the names are not clear enough.
There are public methods like add_implicit_profiles and commit that even with the comments I don't feel like I understand when to call them and if it is needed to call them at all.
Aren't stream_bridge::is_explicit and stream_bridge::is_implicit opposites?

I kind of feel like the bridge should be dds_sensor_based_device_sensor inheriting from dds_device_sensor, and maybe even in the application level not realdds.

[OhadMeir]

We should add this test to dds_device_server too. No use of a device without streams.

[maloel]

I think we have a test (see test-device-init.py) where this is a valid scenario.

[OhadMeir]

Then we should reconsider if it is valid. Not a must for this PR, but a point to consider, is there a point in a device without any streams.

[maloel]

How about a DFU device? I can see situations where a device is strictly for the control/notification mechanism. I agree it's then not strictly a "device" but we'll only know later if this makes sense or not.

[OhadMeir]

I don't have any more comments at the moment.

I still don't like the name dds_stream_sensor_bridge and the naming of some of it's methods but I don't have better names.

[OhadMeir]

I am OK with this PR. If we will want to rename things we can do it some other time