Add functions to get a compatible QoS profiles

[jacobperron]

Connects to #304

Given one or more publisher (subscription) QoS profiles, modify the given subscription (publisher) QoS profile such that it is compatible with most of the publisher (subscription) profiles.
Do this while not sacrificing the level of service when possible.

This API is ultimately intended to be leveraged by ROS tools that typically want to be flexible with respect to the QoS when subscribing or publishing to a topic.

---

Opening for early feedback about the API. There is a reference implementation for one of the functions in ros2/rmw_dds_common#59

My next step is to add rcl functions that query the ROS graph to collect QoS info and then use this API to return the most compatible QoS profile, e.g.

rcl_ret_t rcl_get_compatible_subscription_qos_from_topic(
  const rcl_node_t * node,
  const char * topic_name,
  rmw_qos_profile_t * subscription_qos_profile
)

I'm leaning towards putting the endpoint query logic in rcl, since it can be implemented in an RMW-agnostic way (using the API proposed in this PR). However, we could also consider doing all of that logic in RMW in case the RMW implementation can do something more efficient 🤷

[jacobperron]

Here's a WIP PR for rcl: ros2/rcl#976

[wjwwood]

lgtm

[wjwwood]

Suggested change

	* \return `RMW_RET_OK` if the operation was successful, or
	* \return `RMW_RET_INVALID_ARGUMENT` if `publisher_profiles` is `nullptr`, or
	* \return `RMW_RET_INVALID_ARGUMENT` if `publisher_profiles_length` is 0, or
	* \return `RMW_RET_INVALID_ARGUMENT` if `subscription_profile` is `nullptr`, or
	* \return `RMW_RET_OK` if the operation was successful, or
	* \return `RMW_RET_INVALID_ARGUMENT` if `subscription_profiles` is `nullptr`, or
	* \return `RMW_RET_INVALID_ARGUMENT` if `subscription_profiles_length` is 0, or
	* \return `RMW_RET_INVALID_ARGUMENT` if `publisher_profile` is `nullptr`, or

[j-rivero]

Suggested change

	* \param[out] subscription_profile: QoS policies that are compatible with the majorty of
	* \param[out] subscription_profile: QoS policies that are compatible with the majority of

A side from the typo, could it be that "majority" is somehow ambiguous here? I mean, we probably want to know if the policy is "compatible enough" to be used and that implies that is compatible with all input publisher profiles. Is my understanding correct?

[jacobperron]

For DDS implementations, it will be compatible with all input publisher profiles, but I'm purposefully using the word "majority" here to leave room for non-DDS implementations that may not be able to match all input publishers (their QoS compatibility rules may be different).

[ivanpauno]

I have one suggestion.
I'm not sure if compatible_subscription_profiles/compatible_publisher_profiles will be useful in practice, but having them is okay.

[ivanpauno]

Could we have a RMW_RET_MOST_COMAPATIBLE_NOT_ALL?
Or sth like that, to indicate that the returned profile is not compatible with all the provided profiles, without the need of providing a compatible_publisher_profiles array.

[jacobperron]

I'm open to that idea. My original thinking was that if there are one or more incompatible profiles, then the user could invoke this function again with just those profiles in an effort to match them. But, as you point out, I'm not sure if this would be used in practice 🤷

[wjwwood]

We could do that, but is that better than the array? It seems like the array just provides strictly more information. If the function tells me it matches some but not all, my immediate next question is "which ones"? At least that's my thinking.

[wjwwood]

I think RMW_RET_MOST_COMAPATIBLE_NOT_ALL and the array could be useful (the array is optional btw), just because it is easier for the caller to check, rather than always requesting the array and then iterating over it to know if it's a 100% fit or only a partial fit.

[jacobperron]

I like the new return code in addition to the output array of booleans; I can add it.

I considered the array of bools a compromise; because we could alternatively return an array of structs describing precisely what QoS policies are compatible, incompatible, or unknown for each input QoS profile. This seems like it would add a lot of detail and implementation overhead for something I'm not sure anyone would use.

[wjwwood]

I considered the array of bools a compromise; because we could alternatively return an array of structs describing precisely what QoS policies are compatible, incompatible, or unknown for each input QoS profile. This seems like it would add a lot of detail and implementation overhead for something I'm not sure anyone would use.

That's fair, I guess knowing which it is not compatible with doesn't tell you much more, but I guess then there are direct comparison functions, where you could compare the one it didn't match with the one it proposed and get more details on why they don't match that way.

[fujitatomoya]

looks good to me.

[jacobperron]

See #320 (and connected PRs) for an alternative to this PR. IMO, it makes the interface a lot nicer for the user for a couple reasons:

• They only have to change the QoS policy value in order to take advantage of the feature; instead of calling extra functions and doing error handling.
• They can choose which policies they was to be adaptive; it's not all-or-nothing like this PR.

[jacobperron]

Closing in favor of #320