DDS15 — Request/Offered behavior of DURABILITY Qos does not match use-cases

The DURABILITY Qos is defined as Request/Offered. If a DataWriter offers a kind, the DataReader 'request' kind must be 'less or equal'. Otherwise they will not match, for this comparison it is considered that
VOLATILE < TRANSIENT_LOCAL < TRANSIENT < PERSISTENT.

This is not intuitive to users and does not match many of the use-cases observed in practice.

What users expect is for a DataWriter to configure its durability without impact on the matching (very much like HISTORY). The setting would just control whether the DataWriter keeps a local copy of the data for late joiners and whether it sends the data to the persistence services.

The reader in the other hand should simple state whether it wants "historical data" meaning data that was published before the reader joined the domain. This could just be a "boolean" or maybe a boolean plus some extra information that controls how much "historical data" to get.

If the DataWriter enabled durability then it would get the data that the DataWriters have on their "historical cache" that includes data from the Persistence services.

If a DataWriter set DURABILITY to TRANSIENT or PERSISTENT, then it would send its data to the PERSISTENCE services. It it was 'TRANSIENT LOCAL" then the Persistence service would not match the writer.

Ideally this could be done as an extension so it has minimal impact in current behavior or interoperabiity