Fix enum undef ts bug35

[bhill-slac]

When support for propEventCB was added to the gateway, it subscribed to DBR_CTRL_* but calls both runDataCB and runValueDataCB. Since the DBR_CTRL_* events have zero in the timestamp fields and the value_data_callbacks assign the gdd from the DBR_CTRL* event to the gatePv value gdd, it can step on the timestamp from the DBR_TIME_* event.

I suspect the code in gatePvData::propEventCB was ignoring the first propEvent to avoid this bug but some cases get through and set the timestamp fields to zero, in particular mbbi and mbbo records.

This fix creates to subcriptions for DBE_PROPERTY events, one DBR_CTRL* subscription w/ propDataCB, and a DBR_TIME* subscription w/ propEventCB.

[ralphlange]

This pull request fails the tests on all different architectures.
Main issue, which seems directly related to the changes in this PR:

make[3]: Entering directory '/home/runner/work/ca-gateway/ca-gateway/testTop/pyTestsApp/O.linux-x86_64'
  ======================================================================
  FAIL: Monitor PV (imitating CS-Studio) through GW - change value and properties directly - check CTRL structure consistency
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File "/home/runner/work/ca-gateway/ca-gateway/testTop/pyTestsApp/TestCSStudio.py", line 93, in testCSStudio_ValueAndPropMonitor
      self.assertTrue(are_diff == False,
  AssertionError: False is not true : At update 3 (change value), received structure updates differ:
  	Element 'value' : GW has '0.0', IOC has '10.0'
  	Element 'ftype' : GW has '34', IOC has '20'
  	Element 'status' : GW has '17', IOC has '4'
  	Element 'severity' : GW has '3', IOC has '1'
  	Element 'timestamp' : GW has '631152000.0', IOC has '1653[43](https://github.com/epics-extensions/ca-gateway/runs/6583342460?check_suite_focus=true#step:8:44)5554.5943'
  	Element 'posixseconds' : GW has '6311[52](https://github.com/epics-extensions/ca-gateway/runs/6583342460?check_suite_focus=true#step:8:53)000.0', IOC has '16[53](https://github.com/epics-extensions/ca-gateway/runs/6583342460?check_suite_focus=true#step:8:54)4355[54](https://github.com/epics-extensions/ca-gateway/runs/6583342460?check_suite_focus=true#step:8:55).0'
  	Element 'nanoseconds' : GW has '0', IOC has '[59](https://github.com/epics-extensions/ca-gateway/runs/6583342460?check_suite_focus=true#step:8:60)4300114'
  
  ======================================================================
  FAIL: DBE_PROPERTY monitor on an ai - value changes generate no events; property changes generate events.
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File "/home/runner/work/ca-gateway/ca-gateway/testTop/pyTestsApp/TestDBEProp.py", line [60](https://github.com/epics-extensions/ca-gateway/runs/6583342460?check_suite_focus=true#step:8:61), in testPropAlarmLevels
      self.assertTrue(self.eventsReceivedGW == 1, 'GW events expected: 1; received: ' + str(self.eventsReceivedGW))
  AssertionError: False is not true : GW events expected: 1; received: 2
  
  ----------------------------------------------------------------------

Please either fix the changes or the test.

[bhill-slac]

Looks like the test just needed to adjust the expected eventsReceived counts.
This is expected as the gateway w/ this branch is doing two subscriptions instead of one.

[ralphlange]

Thanks a lot, Bruce!
I had an idea but was not 100% sure if the code or the test needed changing.

[kasemir]

Is something blocking a merge of this pull request?

When support for propEventCB was added to the gateway, it subscribed to DBR_CTRL_* ...

This fix creates to subcriptions for DBE_PROPERTY events, one DBR_CTRL* subscription w/ propDataCB, and a DBR_TIME* subscription w/ propEventCB.

I clearly don't understand the details, but this seems related to #56:

A client subscribes to the DBR_TIME_... variant of an array (double[] in this case). The array changes size; at times it turns into an empty array, zero elements. The client receives the array with its changing size via the gateway without problems.

Then the client adds a DBE_PROPERTY subscription to DBR_CTRL_... to learn about changes in units, limits etc. With full logging enabled, the gateway will print

gateVcData::read() increasing highestGddAppType to 34

Type 34 is the control-double type, so this rhymes with "When support for propEventCB was added to the gateway, it subscribed to DBR_CTRL_*".
From now on, whenever the array size becomes zero, the gateway will unfortunately turn this into an update with value '0'. Hard to say if that's an array with one 'zero' element, or a scalar with value 'zero', since both look like a DBR_..._DOUBLE with one element.

The underlying problem seems to be that the gateway maintains one cached copy of the data for the channel. It starts as a DBR_TIME_.. subscription for the value. As the client then asks for a DBE_PROPERTY subscription to DBR_CTRL_.., the data type of the gateway PV is updated to "highestGddAppType" DBR_CTRL_..., but there's a problem with both the value and the property subscription updating the same PV data, turning the empty array into '0'.

"This fix creates (separate) subscriptions for DBE_PROPERTY, .. one DBR_CTRL* ...and a DBR_TIME* subscription" seems to be a step in the right direction, alas when I try this PR, it doesn't fix #56

[ralphlange]

I will try to run the tests using this PR. (Test failures were my original concern.)

[ralphlange]

General remark:
The moment we're generating more subscriptions and traffic on the Gateway's IOC side than on the client side, the original intention of the Gateway (reducing load on the IOC side) gets threatened.
Having the Gateway generate wrong data is worse, so this truly is a general remark.

[kasemir]

Turns out this enum time stamp issue, while it mentions DBE_PROPERTY, is unrelated to the issue with empty arrays and a DBE_PROPERTY subscription to DBR_CTRL, #56

The issue I see is solely related to the handling of DBE_PROPERTY subscriptions, regardless of DBE_.. mask. Some "if (count <= 0)` code simply failed to handle array element counts of zero.

Created separate PR for the empty array issue