Merge attributes of key group and value dataset for CONTROL keys

[philsmt]

Unfortunately I noticed that the HDF attributes mapping to Karabo properties at the time of recording are a bit all over the place in the case of CONTROL keys. For example, SA3_XTD10_XGM/XGM/DOOCS.beamposition.ixPos for a recent run:

├21 attributes:
│ ├accessMode: [2]
│ ├alias: 'IX.POS'
│ ├assignment: [0]
│ ├daqPolicy: [-1]
│ ├defaultValue: [-1.]
│ ├description: 'Calculated X position [mm]'
│ ├displayedName: 'X'
│ ├frac: [0]
│ ├leafType: [0]
│ ├metricPrefixEnum: [13]
│ ├metricPrefixName: 'milli'
│ ├metricPrefixSymbol: 'm'
│ ├nodeType: [0]
│ ├requiredAccessLevel: [0]
│ ├sec: [0]
│ ├tags: ['doocs' 'poll']
│ ├tid: [0]
│ ├unitEnum: [2]
│ ├unitName: 'meter'
│ ├unitSymbol: 'm'
│ └valueType: 'FLOAT'
├timestamp	[uint64: 500]
│ └4 attributes:
│   ├daqPolicy: [1]
│   ├frac: [0]
│   ├sec: [0]
│   └tid: [0]
└value	[float32: 500]
  └12 attributes:
    ├alias: 'IX.POS'
    ├daqPolicy: [1]
    ├frac: [0]
    ├metricPrefixEnum: [13]
    ├metricPrefixName: 'milli'
    ├metricPrefixSymbol: 'm'
    ├sec: [0]
    ├tags: ['doocs' 'poll']
    ├tid: [0]
    ├unitEnum: [2]
    ├unitName: 'meter'
    └unitSymbol: 'm'

After scanning through attributes across a large number of sources, I found:

• In all cases except one (minSize, not shown here), the keys on value are a true subset of the parent
• Duplicate attributes in value either have the same value (e.g. alias above) or a wrong, likely constant value (e.g. daqPolicy)
• timestamp always has exactly the four attributes with exactly those values as shown above

Based on that, this PR merges the attributes on the parent group into those returned from KeyData.attributes() for the value dataset of a key, specifically overwriting any existing key.

[philsmt]

Fixes #495

[takluyver]

Let's also mention here that at least currently, some overlapping attributes differ, and in that case the group level attribute seems to be the one that's right.

(I have a nasty foreboding that some day we'll come across a case where the group attribute is wrong and the dataset attribute is right, and we'll have to figure out how to wrangle that. But hopefully that's just pessimism. 🤞 )

[tmichela]

(I have a nasty foreboding that some day we'll come across a case where the group attribute is wrong and the dataset attribute is right, and we'll have to figure out how to wrangle that. But hopefully that's just pessimism. 🤞 )

I don't think that's a possibility.
The attributes come from the device schema. The HDF5 datasets .value and .timestamp don't exist on the device. The parent group of those datasets, is actually (on the device) the property leaf that holds the value and attributes on the device we're saving.

So the attributes on these dataset must be copied from the parent group (or have some default). I guess the wrong default could as well be on the parent group, but I don't see how this could be wrong on the parent group and correct on the dataset.

[philsmt]

Good point, added that clarification.

In general though, I wouldn't worry much. I'll get in touch with the DAQ team and asked them to verify our assumptions here.

We may even be able to remove the dataset attributes entirely again and shift EXtra-data to the ones on the group. Frankly I doubt users would notice.

[takluyver]

Other than that, LGTM. 👍

[takluyver]

Thanks, LGTM!

[philsmt]

Thanks for review.