Add design document on configuring QoS at startup time

[jacobperron]

Add design document on configuring QoS at startup time

[ivanpauno]

I've renamed the issue from runtime to startup time.
Re-configuring QoS profiles at runtime is much harder, and not what the original issue was aiming for (the three linked workarounds are for startup qos configuration).

The idea is to have a way to externally configure the QoS settings when reusing a node someone else has written.
For different use cases, different QoS profiles may be desired.

This also matches what DDS allows.

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/transport-priority-qos-policy-to-solve-ip-flow-ambiguity-while-requesting-5g-network-qos/15332/2

[gbiggs]

This is possibly something that can be done via a set of well-known parameters. Maybe have the node base implementation check for those parameters when it creates publishers and subscribers, and use the QoS values from them if they exist?

I strongly agree with this comment about whether nodes should allow overriding or not. The node author is responsible for defining the allowable range of behaviour of their node, and that includes what range of QoS values it can support. They need to be able to prevent certain values being set. This is also something that the parameters mechanism could be leveraged to support, with its ability to reject certain parameter values.

Although a dedicated API that hides how it is being done could be useful.

[jacobperron]

A design doc was added in #300.
And subsequently implemented in ros2/rclcpp#1408 and ros2/rclpy#635