Support QoS override parameters in depth_image_proc/register (backport #1043)

[mergify]

Hi! This is my first PR to ROS2. Please let me know if there are steps I'm missing or additional things you'd like me to check.

This PR adds support to the depth_image_proc - register node for setting External QoS Configuration on topic subscriptions.

Why?

Sensors are often published with the SENSOR_DATA profile, which cannot be read by subscribers expecting the default QoS profile, as the default profile specifies a reliability == reliable requirement. The SENSOR_DATA profile uses reliability == best_effort, making these publishers and subscribers incompatible.

Because depth_image_proc - register does not provide a way to modify the expected QoS of the topic subscriptions, it cannot subscribe to topics published by other nodes which use the SENSOR_DATA profile.

ROS2's solution to this common problem is to allow External QoS Configuration through the parameter system. While depth_image_proc - register supports External QoS Configuration on published topics, it does not support it on subscribed topics.

This PR adds support for External QoS configuration on subscribed topics.

How?

• Add the same qos_overriding_options = rclcpp::QosOverridingOptions::with_default_policies() option to all topic subscriptions that is also used on the topic publishers

Testing

• Compiled on latest pull of ROS2 Rolling

$ colcon build --packages-up-to depth_image_proc
Starting >>> tracetools_image_pipeline
Finished <<< tracetools_image_pipeline [0.22s]
Starting >>> image_proc
Finished <<< image_proc [0.58s]
Starting >>> depth_image_proc
Finished <<< depth_image_proc [20.3s]

Summary: 3 packages finished [21.3s]

• Compiled and live-tested on ROS2 Jazzy (jazzy branch of my fork). This is the same change that was applied to rolling
• Recompiled depth_image_proc and launched with QoS remapping arguments using a launch file (on an in-progress robot project):

    Node(
            package='depth_image_proc', 
            executable='register_node', 
            name='depth_register',
            parameters=[
                {'qos_overrides./loomo/realsense/color/image_color/camera_info.subscription.reliability': 'best_effort'},
                {'qos_overrides./loomo/realsense/depth/image_depth/camera_info.subscription.reliability': 'best_effort'},
                {'qos_overrides./loomo/realsense/depth/image_depth.subscription.reliability': 'best_effort'},
            ],
            remappings={
                # in
                ('rgb/camera_info', '/loomo/realsense/color/image_color/camera_info'),
                ('depth/camera_info', '/loomo/realsense/depth/image_depth/camera_info'), 
                ('depth/image_rect', '/loomo/realsense/depth/image_depth'),
                # out
                ('depth_registered/camera_info', '/loomo_synthetic/realsense/depth_registered/image_depth/camera_info'),
                ('depth_registered/image_rect', '/loomo_synthetic/realsense/depth_registered/image_depth')
            },
        ),

Checked for the presence of new parameters in rqt_gui:

• Observed that new QoS Parameters for subscribed topics are present and are being set by the launch parameters
• Observed that depth_image_proc - register is now accepting messages from topics publishing with the SENSOR_DATA QoS profile with QoS overrides applied

  ---

  This is an automatic backport of pull request Support QoS override parameters in depth_image_proc/register #1043 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 0dd99bf has failed:

On branch mergify/bp/jazzy/pr-1043
Your branch is up to date with 'origin/jazzy'.

You are currently cherry-picking commit 0dd99bf.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   depth_image_proc/src/register.cpp

no changes added to commit (use "git add" and/or "git commit -a")

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally