Fix content filtering on Windows with modern Connext DDS

[mjcarroll]

Description

This PR fixes Content Filtering on Windows when using modern versions of RTI Connext DDS (6.x and 7.x).

The Problem

Previously, the rmw_connextdds implementation on Windows was forced into a "Compatibility Mode." This mode:

1. Disabled Writer-side filtering: All samples were sent to all matching readers, regardless of whether they matched the filter.
2. Forced Reader-side filtering: Filtering was performed after deserialization. However, the built-in RTI SQL filter expects samples in the Connext memory layout. Because ROS 2 uses its own internal format, the filter would fail "open" and accept all samples.

This led to failures in rcl, rclcpp, and rcl_action tests where samples were received by subscribers despite being explicitly filtered out by SQL expressions.

The Fix

1. Enable Serialized Evaluation: Updated CMakeLists.txt to only enable RMW_CONNEXT_BUILTIN_CFT_COMPATIBILITY_MODE on Windows for Connext versions older than 6.0.0. For modern versions, we now use the internal register_contentfilterI API, which supports evaluation on CDR-serialized samples.
2. Fix Redefinition Conflict: Adjusted custom_sql_filter.hpp to use the official RTI declaration of register_contentfilterI (available in modern headers) to avoid linkage errors on MSVC.
3. Correct Cookie Handling: Fixed a bug in RTI_CustomSqlFilter_writer_evaluated_result where it assumed RTI's built-in filter always returned a discontiguous sequence of cookies. It now correctly handles both contiguous and discontiguous sequences.

Verification

Verified on Windows using a targeted CI run with Connext 7.7.0. All content filtering tests in rcl, rclcpp, and rcl_action passed.

CI Result (Windows 10, Connext 7.7.0): https://ci.ros2.org/job/ci_windows/27743/

Is this user-facing behavior change?

No, it fixes a regression in existing functionality.

Did you use Generative AI?

Yes. Gemini CLI:2.0-Flash [web_fetch, run_shell_command, replace, git, gh]

[mjcarroll]

Pulls: #226
Gist: https://gist.githubusercontent.com/mjcarroll/916220ac5820e6bc62eebe971ce41f85/raw/6a2085453c76d5d8154be7261de0001cc179ed38/ros2.repos
BUILD args:
TEST args:
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/19089

• Linux
• Linux-aarch64
• Linux-rhel
• Windows

[fujitatomoya]

lgtm, @fgallegosalido can you take a look?

[fgallegosalido]

It looks good to me. I just have one question. Has the bug in the cookie handling actually happened while investigating this issue? I checked internally and that buffer is going to always be discontiguous (a buffer of pointers to DDS_Cookie_t). Therefore, that check is redundant. It doesn't hurt having it there, but unless there is an actual bug, it is not necessary.

Maybe, we can add a comment above that check explaining that the buffer is always going to be discontiguous.

Thank you very much @mjcarroll for looking into this!