DDSXTY — Allow more flexible type consistency enforcement

Summary:
Section 7.6.1.3.1, TypeConsistencyEnforcementQosPolicy: Conceptual Model, identifies the type consistency enforcement kinds. This QoS policy is request-offer (RxO); readers and writers must match exactly in order to communicate. However, this requirement for an exact match is not required by implementations and is too restrictive for users.

The resolution below is closely related to the resolutions of issues #16097 and #16561.
The existing type consistency enforcement QoS policy, which governs both type signature consistency and type definition structural consistency, shall be simplified. It shall be removed from the Topic and DataWriter QoS and the corresponding built-in topic data types. It shall remain in the DataReader QoS and in the Subscription built-in topic data type. Its “kind” enumeration shall have the following values:
• DISALLOW_TYPE_COERCION: The DataWriter and the DataReader must support the same data type in order for them to communicate.
• ALLOW_TYPE_COERCION: The DataWriter and the DataReader need not support the same data type(s) in order for them to communicate as long as the reader’s type is assignable from the writer’s type.
The default settings shall be as follows:
• For compliant readers: ALLOW_TYPE_COERCION
• Inferred for non-compliant readers: DISALLOW_TYPE_COERCION
Type compatibility shall be determined according to the following steps:s
1. The TypeObject type definition is considered first, provided that it is available for both the Publication and the Subscription. (This is anticipated to be the most common case for DDS-XTypes-conformant implementations.) If the Subscription allows type coercion, then its type must be assignable from the type of the Publication. If the Subscription does not allow type coercion, then its type must be equal to that of the Publication.
2. If either the Publication or the Subscription does not provide any TypeObject definitions, then the type names are consulted. (This case is important in cases where a given component cannot, or does not wish to, provide concrete type definitions. For example, it may not support XTypes, it may wish to conserve bandwidth, it may not wish to reveal its type definition(s), or it may not even be type-aware—it may simply record binary payloads, for example.) The Subscription and Publication type_name fields must match exactly.
If the reader and writer are not type-compatible, the middleware raises an INCONSISTENT_TOPIC status change.
The following behaviors will result from the default values and evaluation orders above when writers and readers have default QoS:
• Compliant writers will communicate with compliant readers. The reader will allow type coercion. This behavior is what we want, and it is unchanged from the current DDS-XTypes default.
• Compliant writers will communicate with non-compliant readers. The reader will not allow type coercion, so the types (really the type names) must match exactly. This behavior is unchanged from the implied contract of DDS implementations prior to DDS-XTypes.
(Suppose the writer has out-of-band knowledge of the reader’s type definition. If the writer determines that the types are not equal, it will consider the topic inconsistent and forbid communication. The reader will be unable to detect this inconsistency. However, the reader will not receive any data from the writer, so deserialization errors will be prevented just the same.)
• Non-compliant writers will communicate with compliant readers. The reader will allow type coercion. This behavior provides maximum flexibility without requiring changes to deployed non-compliant applications.
(Suppose the reader has out-of-band knowledge of the writer’s type definition. If the reader determines that the types are not assignable, the writer will be unable to detect this inconsistency and may send data to the reader nonetheless. The reader implementation will need to detect and eliminate this extraneous data without attempting to deserialize it—for example, by checking upon receiving the data from the socket whether the source data is actually from a matched writer. This edge case is little different from other preexisting cases, such as the use by a non-matching writer of a multicast address used by the reader. Therefore, it is not expected to be a barrier to implementation.)