Use pvRequest to mask monitor updates

[mdavidsaver]

Need to translate the pvRequest 'fields' sub-struct into a BitSet and use it to mask out Monitor updates. This will all a client to monitor part of a structure (eg. alarm but not value).

[anjohnson]

I agree with @mrkraimer 's comment in epics-base/pvDataCPP#51 that if a request (and this doesn't just apply to monitor requests) is for a specific set of fields, the server shouldn't be sending anything else along with them. That was a fundamental design feature of pvAccess; a client may know that one of the other fields holds a large array which it is explicitly not requesting as it might not have the bandwidth for it, or maybe it's an alarm handler which monitors many PVs but has no interest in their value fields.

A pvaSrv IOC sends exactly what was asked for, so this behavior of pva2pva is a regression for the project as a whole, I don't see it as just an enhancement request.

Running pvaSrv's testDbPv IOC:

tux% bin/linux-x86_64/pvget -r "alarm,timeStamp" doubleArray03
doubleArray03
structure 
    alarm_t alarm NO_ALARM NO_STATUS NO_ALARM
    time_t timeStamp 2018-02-07T12:18:53.143 0

Running the Base-7.0 softIocPVA with the same database:

tux% bin/linux-x86_64/pvget -r "alarm,timeStamp" doubleArray03
doubleArray03
epics:nt/NTScalarArray:1.0 
    double[] value [1,2,3,4,5]
    alarm_t alarm NO_ALARM NO_STATUS NO_ALARM
    time_t timeStamp 2018-02-07T13:24:01.667 0
    display_t display
        double limitLow 0
        double limitHigh 10
        string description 
        string format 
        string units Counts
    control_t control
        double limitLow 0
        double limitHigh 10
        double minStep 0
    valueAlarm_t valueAlarm
        boolean active false
        double lowAlarmLimit nan
        double lowWarningLimit nan
        double highWarningLimit nan
        double highAlarmLimit nan
        int lowAlarmSeverity 0
        int lowWarningSeverity 0
        int highWarningSeverity 0
        int highAlarmSeverity 0
        double hysteresis 0

[mdavidsaver]

In this discussion I'm trying to make a distinction between whether the provided Structure has some field, and whether changes to this field are ever sent. Right now, fields are always present, and changes are always sent. After I have time to address this, fields will still always be present, however changes will be sent subject to the pvRequest blob.

Technically it will probably be something like:

1. Given a pvRequest blob and a Structure, create a BitSet describing all of the fields being selected. Call this selectedMask.
2. This BitSet would then be combined with the changedMask associated with a potential subscription update by changedMask &= selectedMask. So only those selected and changed fields are sent, and the whole will be dropped if the result is an empty set.

[mdavidsaver]

As mention in epics-base/pvDataCPP#51 (comment). When I next have time I'll be changing QSRV to use SharedPV (epics-base/pvAccessCPP#111). This will bring along the functionality of PVRequestMapper as described here epics-base/pvDataCPP/pull/56 and https://github.com/epics-base/pvDataCPP/blob/d776f6eaf03c058597c05b3308636d95223b6c6e/src/copy/pv/createRequest.h#L68-L74

epics-base/pvAccessCPP#129 is also relevant as unused, or unchanging, fields are no longer printed except with full detail pvmonitor -vvv ...