Elevate RUN-only keys to the same level as CONTROL keys?

[philsmt]

At the moment, EXtra-data treats keys that have only RUN but no CONTROL values as separate. They are not listed as part of SourceData.keys() and cannot have a KeyData object associated with them. The only way to access them is via the dedicated SourceData.run_values() interface. On the Karabo side as far as I can see, a property primarily ends up not having a CONTROL section when its daqPolicy attribute is set to IGNORE or its type is not supported for train-resolved data (e.g. strings).

While I'm not aware of any critical properties affected by this, I did encounter a couple of very useful properties recently that only have RUN values beyond technical ones like deviceClass. The PulsePatternDecoder e.g. indicates the laser source it is set to watch for in such a way, there are spectrometer devices saving the background they substracted at runtime this way and finally string settings useful to interpret the operating mode a particular device had.

The biggest gripe I have with this situation is discoverability by not being included in SourceData.keys(), in particular combined with the fact they are somewhat mentioned in DataCollection.info(). After all, they haven been a property of the original device, they just happen to not be train-resolved. Including them in SourceData.keys() however implies that SourceData[<key>] should now throw a PropertyNameError and thus open a much larger issue of supporting such keys in some way in the KeyData interface. I don't think this is impossible however and could immediately think of two ways:

• Make KeyData aware and throw exceptions (or return empty result?) in all train-based methods (e.g. .select_trains(), .ndarray()) while supporting others (.entry_shape, .as_single_value())
• Use different RunData class to achieve the same effect