Unique network flows optional checks

[thomasmoore-torc]

Description

As part of #711, the ros_discovery_info subscription was configured with RMW_UNIQUE_NETWORK_FLOW_ENDPOINTS_OPTIONALLY_REQUIRED. However, there are no criteria under which an optional unique network flow is actually optional and it ultimately behaves exactly the same as setting RMW_UNIQUE_NETWORK_FLOW_ENDPOINTS_STRICTLY_REQUIRED. There are several conditions under which unique network flows are not supported:

1. When locators are explicitly specified (relevant Fast DDS docs) - this results in FastDDS generating an error if unique network flow is requested when locators are explicitly specified
2. When static EDP is utilized (Unique Network Flows and Static Endpoint Discovery are incompatible eProsima/Fast-DDS#6348) - this results in user data not being received by the subscriber

The intent of this PR is to incorporate checks for these conditions such that a unique network flow will not be requested under these conditions when a subscription is created with RMW_UNIQUE_NETWORK_FLOW_ENDPOINTS_OPTIONALLY_REQUIRED. It also adds the RMW_FASTRTPS_USE_UNIQUE_NETWORK_FLOWS_FOR_ROS_DISCOVERY_INFO environment variable to enable the ability to disable requesting uinique network flows for the ros_discovery_info topic.

Is this user-facing behavior change?

This will enable the user to utilize features such as explicit locator specification or static EDP via the Fast DDS XML configuration files. It will also give the user the option to disable unique network flows for the ros_discovery_info topic.

Did you use Generative AI?

Claude Opus 4.6 was used via GitHub Copilot to assist with the analysis of the issue and to provide an initial implementation. The implementation was then manually refined.

Additional Information

We would like to backport this to Jazzy.

[thomasmoore-torc]

It appears that the build is failing because e5c8a84 requires ros2/rmw@403ee71, but the build is utilizing rmw version 7.9.1-1noble.20260317.155120, which doesn't include ros2/rmw@403ee71.

I don't currently have permissions to the ci_launcher, so I'm unable to trigger a build with the needed version of rmw for the test to pass.

[fujitatomoya]

test would be ideal to add.

[fujitatomoya]

the function is declared in the header with RMW_FASTRTPS_SHARED_CPP_LOCAL, meaning it has hidden visibility and isn't exported from the shared library. however, it's called from rmw_fastrtps_cpp and rmw_fastrtps_dynamic_cpp, which are separate libraries???

Suggested change

	RMW_FASTRTPS_SHARED_CPP_LOCAL
	RMW_FASTRTPS_SHARED_CPP_PUBLIC

[thomasmoore-torc]

That's a good point. We build statically, so it's not an issue in our build environment. I was attempting to try and avoid an ABI break so that this can be back-ported to Jazzy. I think the only way to allow for back porting to Jazzy and allowing for ABI compatibility would be to duplicate the function in both rmw_fastrtps_cpp and rmw_fastrtps_dynamic_cpp. Are there any other options we can consider?

[fujitatomoya]

does this evaluate every context init? a static cached value with std::call_once would be more robust if multiple contexts are initialized concurrently with assumption that env variable does not change in the process space?

[thomasmoore-torc]

I can make that change. However, no such mechanism is currently used for the other environment variables that are read during participant creation, such as FASTRTPS_DEFAULT_PROFILES_FILE, RMW_FASTRTPS_USE_QOS_FROM_XML, and RMW_FASTRTPS_PUBLICATION_MODE.

[MiguelCompany]

Apart from my comment below, this needs a rebase

[MiguelCompany]

I would make this directly return rmw_unique_network_flow_endpoints_requirement_t.
We can then discuss whether we want the new env var to be ON/OFF, or if we want it to set a specific value (i.e.
DISABLED / OPTIONAL / STRICT / DEFAULT)

Suggested change

	bool
	use_unique_network_flows_for_ros_discovery_info();
	rmw_unique_network_flow_endpoints_requirement_t
	get_unique_network_flows_for_ros_discovery_info();