fix(LibCarla/ros2): add REP-2011 type hashes and shared FastDDS participant for Jazzy compatibility

[JArmandoAnaya]

Description

Fixes two ROS 2 Jazzy interoperability problems in the native DDS integration.

1. Missing REP-2011 type hash on every topic (#9674)

ROS 2 Iron and later RMWs (rmw_fastrtps_cpp, rmw_cyclonedds_cpp) parse the DDS USER_DATA QoS field during SEDP/PDP endpoint discovery and expect a REP-2016 KV payload of the form typehash=RIHS01_<64-hex>;. When the payload is absent, the RMW logs for every discovered endpoint:

[WARN] [rmw_cyclonedds_cpp]: Failed to parse type hash for topic 'rt/...'

CARLA did not set USER_DATA on any of its 31 message types, so running a Jazzy subscriber (rviz2, any ros2 topic echo, any autonomy stack) against a CARLA server produced a warning per topic per endpoint, and prevented future strict type-hash-based endpoint matching.

Fix: hardcode a REP-2011 RIHS01 hash per message type in CdrTopicInfo<T>::type_hash() and attach it via a new UserDataFormat.h::build_user_data_for<T>() helper on every DataWriter and DataReader QoS in both FastDDS and CycloneDDS middlewares. Hashes are hardcoded because CARLA has no IDL code-generation step at build time and recomputing RIHS01 correctly requires rosidl_generator_type_description inside a ROS 2 build environment. The values are stable per distro for every standard message (std_msgs, geometry_msgs, sensor_msgs, nav_msgs, builtin_interfaces, tf2_msgs, rosgraph_msgs, ackermann_msgs) and match on Humble and Jazzy.

A helper script Util/ros2/compute_type_hash.sh computes the RIHS01 hash for any message type using only Docker, so adding a new type needs no local ROS 2 install.

2. FastDDS rt/tf duplicate-topic crash (#9675)

Since the shared DomainParticipant was introduced, multiple sensor publishers on the same actor (or multiple hero actors) all call create_topic("rt/tf", ...) on the same participant. FastDDS rejects duplicate topic creation and aborts the server:

Topic with name : rt/tf already exists -> Function create_topic
ERROR: FastDDSPublisherMiddleware: Failed to create Topic
WARNING: CarlaTransformPublisher: Init failed for topic: rt/tf
Signal 11 caught.

Fix: introduce FastDDSSharedParticipant, a refcounted shared DomainParticipant with per-type registration refcount, and route duplicate topic names through lookup_topicdescription + find_topic so the second and later endpoints reuse the existing topic (balanced by delete_topic in the destructor, which decrements FastDDS's internal topic refcount). CycloneDDS is unaffected (it tolerates duplicate dds_create_topic when types match) but the shared-participant lifetime now drives both middlewares for parity.

The shutdown order in ROS2::Shutdown() also changes: publishers and TF publishers are destroyed before subscribers so DataWriter unregister/dispose messages are sent while the shared participant is still alive.

3. Additional hardening

• carla/multigpu/listener.cpp: treat boost::asio::error::operation_aborted as the normal shutdown path instead of logging Secondary server: Operation canceled. Every graceful CARLA shutdown previously emitted that spurious line.

• Docs/ros2/adding_message_types.md: 7-step guide covering .msg to POD, CDR serialization, RIHS01 computation, CdrTopicInfo registration, and regression tests. Includes a worked sensor_msgs/msg/Imu side-by-side example of the .msg and its POD struct.

Files by area

Area	Files
REP-2011 type hashes	LibCarla/source/carla/ros2/types/CdrTopicInfo.h, LibCarla/source/carla/ros2/types/UserDataFormat.h
FastDDS shared participant	LibCarla/source/carla/ros2/dds/fastdds/FastDDSSharedParticipant.{h,cpp}, LibCarla/source/carla/ros2/dds/fastdds/FastDDSPublisherMiddleware.h, LibCarla/source/carla/ros2/dds/fastdds/FastDDSSubscriberMiddleware.h
USER_DATA on CycloneDDS	LibCarla/source/carla/ros2/dds/cyclonedds/CycloneDDSPublisherMiddleware.h, LibCarla/source/carla/ros2/dds/cyclonedds/CycloneDDSSubscriberMiddleware.h
Shutdown order	LibCarla/source/carla/ros2/ROS2.cpp
Asio shutdown log	LibCarla/source/carla/multigpu/listener.cpp
Build wiring	LibCarla/cmake/ros2/CMakeLists.txt, LibCarla/cmake/fast_dds/CMakeLists.txt
Tests	LibCarla/source/test/server/test_type_hash.cpp (format, uniqueness, USER_DATA payload)
Tooling and docs	Util/ros2/compute_type_hash.sh, Docs/ros2/adding_message_types.md

Fixes #9674
Fixes #9675

Where has this been tested?

• Platform(s): Ubuntu 22.04
• Python version(s): 3.12
• Unreal Engine version(s): UE4.26

Results:

• make LibCarla ARGS="--ros2": clean, zero warnings in changed files.
• libcarla_test_server_release: 120 / 120 pass (includes 4 UserDataFormat.* tests and 2 TypeHash.* tests).
• libcarla_test_server_debug: 120 / 120 pass.
• libcarla_test_client_release: 56 / 56 pass.
• smoke.test_ros2 on port 3654 with --dds-middleware=fastdds and --dds-middleware=cyclonedds: 5 / 5 pass each. FastDDS log is clean of rt/tf already exists, Failed to create Topic, and Signal 11. CycloneDDS log is clean of Secondary server: Operation canceled.
• rviz2 Jazzy (osrf/ros:jazzy-desktop) with RMW_IMPLEMENTATION=rmw_fastrtps_cpp and RMW_IMPLEMENTATION=rmw_cyclonedds_cpp, against CARLA running either middleware: topics discover, type hashes parse, no Failed to parse type hash warnings.

Possible Drawbacks

• Adding a new ROS 2 message type now requires a one-time RIHS01 hash computation through Util/ros2/compute_type_hash.sh. The 7-step workflow is documented in Docs/ros2/adding_message_types.md. No runtime dependency on ROS 2 or rosidl is introduced.

• Hashes are hardcoded per message definition. If a standard ROS 2 message definition ever changes between distros (none of the types currently in CARLA have changed between Humble and Jazzy), the hash for that type must be updated in CdrTopicInfo.h. test_type_hash.cpp validates format and uniqueness but cannot catch a stale value versus an upstream redefinition.

• The refcounted shared participant is FastDDS-only; CycloneDDS uses its own shared participant via dds_create_participant. The two are independent and neither affects the other.

---

This change is 

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would update our CHANGELOG.md based on your changes.

[JArmandoAnaya]

Hello @LuisPovedaCano, This PR is trying to fix the issues #9674 and #9675.

[LuisPovedaCano]

Tested on Jazzy with rmw_cyclonedds_cpp.
RViz2 subscribes to topics cleanly with zero Failed to parse type hash warnings

Great work!

Just two minor changes.

1. In FastDDSSubscriberMiddleware.h, the class doc comment ends mid-sentence in line 40 See FastDDSPublisherMiddleware.h for the
2. The doc comment at the top of CdrTopicInfo.h (lines 59–61) explicitly says:

///                         Returns nullptr for CARLA-specific types whose
///                         canonical hash depends on the carla_msgs package
///                         IDL version — callers must skip setting user_data.

But CarlaCollisionEvent, CarlaEgoVehicleControl, and CarlaLineInvasion all have hardcoded hashes anyway, which contradicts that policy. It's not necessarily wrong, those definitions are stable and CARLA controls them, but either the comment should be updated to reflect that hardcoding carla_msgs hashes is acceptable, or the hashes should be removed and nullptr returned for those three.
As-is it's a bit confusing for anyone adding a new carla_msgs type in the future.

[JArmandoAnaya]

Done! Documentation texts are updated.