Handle missing PID_PARTICIPANT_GUID for readers and writers [9296]

[MiguelCompany]

When receiving EDP information of writers and readers, their participant key can be directly obtained from PID_ENDPOINT_GUID.

This PR ignores PID_PARTICIPANT_GUID on them.

Related to #1380

Signed-off-by: Miguel Company MiguelCompany@eprosima.com

[richiware]

Build status:

• Linux
• Mac
• Windows

[fujitatomoya]

lgtm (at least this is confirmed #1380 (comment))

and DDSI-RTPS v2.3

For optimization, implementations of the protocol shall not include a parameter in the Data submessage if it contains information that is redundant with other parameters already present in that same Data submessage. As a result of this optimization an implementation shall omit the serialization of the parameters listed in Table
9.10.

[MiguelCompany]

Reading DDSI-RTPS v2.3 once more, I am interpreting it the following way:

Section 9.6.2.2 indicates that DiscoveredWriterData is defined with the following IDL:

struct DiscoveredWriterData {
 DDS::PublicationBuiltinTopicData ddsPublicationData;
 WriterProxy mWriterProxy;
};

It then says on Table 9.10 that WriterProxy::remoteWriterGuid does not need to be serialized, as it can be obtained from PublicationBuiltinTopicData::key

Mapping of PID_PARTICIPANT_GUID is specified later on Table 9.14 - ParameterId mapping and default values

This means that field PublicationBuiltinTopicData::participant_key from the DDS v1.4 standard is serialized using PID_PARTICIPANT_GUID. On the default value it says N/A, meaning there is no default value for it, so it should always be sent.

I have modified this PR to handle the case of a missing PID_PARTICIPANT_GUID and in that case default it to using the GUID prefix coming on PID_ENDPOINT_GUID and the default participant entity id

[IkerLuengo]

LGTM

[richiware]

Build status:

• Linux
• Mac
• Windows

[fujitatomoya]

@MiguelCompany @richiware @IkerLuengo

appreciate for the time in such short notice 😄