Check remaining buffer size before allocating C wstring sequences

[florcabral]

Description

#827 added check_sequence_size() to the dynamic sequence deserializers so the serialized length is checked against the remaining input buffer before anything is allocated. The C introspection wstring[] specialization, deserialize_field<std::wstring>(const rosidl_typesupport_introspection_c__MessageMember *, ...), was missed: it reads the 32-bit length and passes it straight to rosidl_runtime_c__U16String__Sequence__init(), which allocates the element array and then calls rosidl_runtime_c__U16String__init() (one 2-byte allocation each) for every element before a single element is read from the wire.

A participant on the same domain can send a sample whose wstring[] field is a length with no element data. Every rmw_fastrtps_dynamic_cpp subscriber using the C type support (rclpy, rclc, C nodes) then dies in one of two ways depending on the length:

• if the element array does not fit the allocator (e.g. 0xFFFFFF00 elements, ~100 GB),
  __Sequence__init() fails and the resulting std::runtime_error escapes deserializeROSmessage(), which only catches Fast-CDR exceptions and std::bad_alloc, and propagates through Fast-DDS and rmw_take(), which catch nothing;
• if it does fit, the per-element initialisation commits memory until the process is OOM-killed.

Either way the subscriber is gone before Fast-CDR reports the truncated buffer (CWE-400 / CWE-770).

This adds the same check_sequence_size() call used by the other sequence paths. A truncated sample now throws NotEnoughMemoryException, which deserializeROSmessage() already catches, so rmw_take() reports the sample as not taken and nothing is allocated.

test_deserialize_sequence_size feeds a hand-built XCDRv1 sample of test_msgs/msg/WStrings whose unbounded_sequence_of_wstrings claims 0x00FFFFFF elements with no element data to the C and C++ introspection type supports and checks that deserialization fails and the sequence stays empty. The length is large enough that an unfixed build allocates about 1 GB and fails the test, and small enough not to take down a CI host.

Verified on rolling (Ubuntu 26.04, Fast-CDR 2.3.6): the test fails with the fix reverted and passes with it; the package test suite including linters passes; populated WStrings messages still round-trip on both type supports.

The same change is needed on jazzy, kilted and lyrical, and on humble, where the file is rmw_fastrtps_dynamic_cpp/include/rmw_fastrtps_dynamic_cpp/TypeSupport_impl.hpp.

[MiguelCompany]

LGTM with green CI

[MiguelCompany]

@ahcorde Since this affects rmw_fastrtps_dynamic_cpp, I relaunched the CI with CI_USE_FASTRTPS_DYNAMIC set to ON:

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