DDS metadata support

[OhadMeir]

This adds metadata support to the DDS.

Metadata and data are synchronized based on frame ID, synchronization is done at LibRS level.
Metadata information is sent using flexible_msg topic, added dds_metadata_stream/server type to handle this stream type.

This is not the final PR for this subject, I want to merge it for now so work done by Eran will not branch to far away from mine. Future PRs will include:

1. metadata supported as part of device_info, not device level option.
2. Remove references to metadata stream names in realdds.
3. Move DDS code from context.cpp to new files to reduce file size and separate dependencies.

[maloel]

If we need a holder to hold information about the frame (whether an extra smart ptr for lifetime or otherwise), how about:

• define a "synced frame" object that has just the relevant information needed by the syncer (i.e., frame-id)
• contains a pointer to the actual frame (as a void*), possibly with a deleter
• if needed, contains any additional pointers (like this holder)

So this class doesn't have to be a template. You deal with your own frame objects and only the callbacks need to know how to interpret the frame (and metadata).

[OhadMeir]

I don't see how to avoid the template using the current rs2_software_video_frame and rs2_motion_video_frame API structs. The syncer still needs to call on_video_frame/on_motion_frame with the correct type.

Changes to the API should be done carefully and in a different PR.

[maloel]

How about a new std::vector( std::move( dds_frame.raw_data ))?

[maloel]

I.e.,

auto p_pixels_vector = new std::vector< uint8_t >( std::move( dds_frame.raw_data ));
rs2_frame.pixels = p_pixels_vector->data();
rs2_frame.deleter = [p_pixels_vector]( void * ) { delete p_pixels_vector; };

[OhadMeir]

The deleter is a plain C function void(*deleter)(void*) so I can't bind lambda parameters

[OhadMeir]

Added to the to-do list a comment about changing the deleter API to receive a parameter.

[maloel]

Not sure what this is doing here... belongs inside create_notifications_reader()?

[OhadMeir]

It is a check before dereferencing _notification_reader in the next line.

[maloel]

Yes I know that... but doesn't create_notifications_reader() throw if it fails?

[OhadMeir]

Did not throw. I moved the check to create_notification_reader function so it will throw from there.

[maloel]

// We can be called multiple times, once per stream

[OhadMeir]

Yes, the first metadata enabled stream will create the reader for the device. Subsequent calls will just return.

[maloel]

Yes meaning you added the comment?

[OhadMeir]

Added now :-)

[maloel]

Any chance this will change during runtime?
Up until now was to set the callbacks before run() is called. I propose that we keep to that and only set the callback if we have a callback.

[OhadMeir]

The callback is set during dds_device_proxy constructor and does not change during runtime.
Still need to check validity before dereferencing.

[maloel]

But that's what I'm saying: if the callback isn't set when we run() then no need to set up another on_data_available callback...

[OhadMeir]

Currently run is being called from on_device_added callback.
The callback is only set later in dds_device_proxy constructor.
@maloel Do you mean to move the call to run into dds_device_proxy constructor? And then I will only check if it is set once when I check _metadata_reader existence?

[OhadMeir]

If so then we need to pass message_timeout_ms parameter to the dds_device_proxy