DDS15 — Clarify the PartitionQosPolicy

It is ambiguous whether or not the PartitionQosPolicy set for a Publisher or Subscriber should affect DataWriter and DataReader matching, and how an implementation should handle it.

Since it is stated that failure to match partitions does not imply "incompatible" QoS, it would seem it does not affect matching.
If so, the specification should be clearer with regards to

• whether this is filtered on the publishing, or subscribing side (or both)
• how partitions are tied to samples or instances e.g. when written from a DataWriter whose Publisher changes partitions intermittently
• how it deals with late joiners and historical data
• how this affects the "transient/persistent" services and their entities' QoS settings

2.2.3 QosPolicy Table

A DataWriter within a Publisher only communicates with a DataReader in a Subscriber if (in addition to matching the Topic and having compatible QoS) the Publisher and Subscriber have a common partition name string.

2.2.3.13 Partitions

For a DataReader to see the changes made to an instance by a DataWriter, not only the Topic must match, but also they must
share a common partition. Each string in the list that defines this QoS policy defines a partition name. A partition name may
contain wildcards. Sharing a common partition means that one of the partition names matches.
Failure to match partitions is not considered an “incompatible” QoS and does not trigger any listeners nor conditions.