The current thinking is that this should be done by using DDS topics which ferry pointers to the published message which the subscriber can access directly without serialization and deserialization. This mechanism is thought to be the best solution because it will allow us to mimic the interprocess DDS topic's QoS more easily. However, it still needs more investigation to show that it is sufficiently efficient and that it actually helps us mimic the external DDS topic's QoS.

AC:

• implement intra-process short cuts in rclcpp for pub/sub (Implement intra process communications for Pub/Sub rclcpp#73)
• add design docs that describe how the system works, any configurations that can be made to the intra-process system, and known issues or drawbacks (https://github.com/ros2/rclcpp/blob/94bf5ffb8ce69aefcddddddbda83af491c5e5938/rclcpp/include/rclcpp/intra_process_manager.hpp#L36-L113) (Implement subscription side filtering when intra process is being used #91) (Audit intra process comms for thread safety #92)
• add example that demonstrates the intra-process functionality (Demo for intra process communication demos#5)
• add tests that exercise the intra-process code paths (adding tests for intra process communications system_tests#28 these could be better, but can be improved when we implement subscription side filtering)

This issue is intentionally scoped to pub/sub to simplify the issue. It is my belief that if it works for pub/sub it will work for services as well.