The class ReaderState encapsulate the Sample, Instance and View States and provides some useful predefined statuses.
However the name of the class is relatively misleading as these statuses have nothing to do with the DataReader.
These statuses are really used to "filter" the data on the reader cache based on its status. The name of the class should
be replaced by something that better express its role.

Resolution
---------------
Rename the "ReaderState" class into "DataStatus".

Rename the "ReaderState" class into "DataStatus".

Description
---------------
The Status API, e.g. sample_rejected_status, deadline_missed_status, etc., are missing from the DataReader.

Resolution
---------------
Simply add them.

The missing statuses methods have been added to the DataReader

The ReaderQuery class bundles together the read-state as well as potential read conditions. However the read-condition is not always present. This leads to code that needs to check all the time wether something is set or not, which is not only very elegant/efficient but it is also error prone

Resolution
---------------
Remove the ReaderQuery and let the read API deal, through proper operations overloads, with ReadState and potential ReadConditions. This way it will always be clear if a read/take is with a condition or not both for the client code and the DDS implementor.

The DataReader API has been updated to provide the proper read/take overloads and remove the useless ReaderQuery. The concept of a Selector has been introduced to orchestrate complex read/take operations requiring selection based on state, content and instance. The new API is orthogonal, simple and composable. Below an example usage of the selector API:

LoanedSamples<Foo> ls =
dr.select()
.instance(handle)
. content(query)
.take();

This example takes the samples matching the query q for the instance with given handle.

The ctors declared by the macros OMG_DDS_REF_TYPE_BASE and OMG_DDS_REF_TYPE_BASE_T for initializing proxy classes with delegates should be declared protected as opposed to public. This will ensure (1) that client code is not able to invoke these methods and (2) that the C++ compiler won't try to apply some of the parametrized ctors to incomplete arg-list provided by the user.

Resolution
---------------
Change ctors declaration from "public" to "protected"

The Reference class ctors identified in this issue were declared “protected”.

The second FTF of the DDS-XTypes spec introduced several API changes that should be incorporated into the DDS-PSM-Cxx spec.

Update the DDS-PSM-Cxx API to reflect the finalization of the X-Type speficication.