[22682] Add RPCDDS internal API

[Carlosespicur]

Description

This PR adds a set of classes that represent all entities required to establish an RPC over DDS Request/Reply communication. All RPC entities should be created from DomainParticipant, so a list of methods has been implemented for this purpose. The main additions are detailed below:

• Requester/Replier/Service interfaces and implementations added. Each Service represent the subset of DDS entities (Topic/Publisher/DataWriter/Subscriber/DataReader) required to establish an RPC Request Reply communication. When a Service is instantiated by a DomainParticipant, Request and Reply topics are created. Each service can instantiate Requester and Replier entities, which are internally registered for entity ownership checking and memory managing. When a Requester is instantiated by a service, a Request Topic DataWriter and Reply Topic DataReader are created. When a Reply is instantiated by a Service, a Request Topic DataReader and Reply Topic DataWriter are created. Both Service and Requester/Replier entities have internal methods to check if all DDS entities are correctly created.

• Requester and Replier objects are created from an instance of RequesterQos and ReplierQos classes respectively. These objects contain the parameters used to configure a Requester/Replier. Before instantiation, a parameter validation at Service level is made. In RPC context, dds entities only accept RELIABLE_RELIABILITY_QOS for reliability QoS.

• Requester/Replier/Service public APIs are represented with abstract classes. Requester/Replier/Service implementation classes inherit from them and implement their own set of methods used for DDS entities creation and internal registering/checking processes.

• Content filtering: Reply samples sent by a replier are filtered by participant using the SampleIdentity's GuidPrefix of its associated request sample. It could be improved adding an internal common identifier for all DDS entities on a given Requester

• Type registering: A ServiceTypeSupport interface has been added for registering service types. In the Request/Reply context, a service type is represented as a pair of topic types (request topic type and reply topic type), so register a service type consists on register both types in DomainParticipant. Registered service types are stored in DomainParticipant and can be accessed by name. register_service_type and unregister_service_type methods have been implemented on DomainParticipant public API

• RPC communication methods: Request and Replier public APIs have methods for sending and taking samples (send_request, send_reply, take_request, take_reply). Send methods call DataWriter write method and Take methods call DataReader take method. The additional information of each request sample sent is represented by RequestInfo class.

• Testing: RPC Blackbox tests refactored to use the new API. Unit tests for service and DomainParticipant added.

Contributor Checklist

• Commit messages follow the project guidelines.
• The code follows the style guidelines of this project.
• Tests that thoroughly check the new feature have been added/Regression tests checking the bug and its fix have been added; the added tests pass locally
• Any new/modified methods have been properly documented using Doxygen.
• N/A: Any new configuration API has an equivalent XML API (with the corresponding XSD extension)
• NO: Changes are backport compatible: they do NOT break ABI nor change library core behavior.
• Changes are API compatible.
• New feature has been added to the versions.md file (if applicable).
• New feature has been documented/Current behavior is correctly described in the documentation.
  • Related documentation PR: Add RPC over DDS internal API documentation Fast-DDS-docs#1032
• N/A: Applicable backports have been included in the description.

Reviewer Checklist

• The PR has a milestone assigned.
• The title and description correctly express the PR's purpose.
• Check contributor checklist is correct.
• If this is a critical bug fix, backports to the critical-only supported branches have been requested.
• Check CI results: changes do not issue any warning.
• Check CI results: failing tests are unrelated with the changes.

[MiguelCompany]

Just some initial architectural concerns

[MiguelCompany]

LGTM with green CI

[MiguelCompany]

Failures unrelated. Going in!