return LINEAR signals with n_samples=1 if n_samples=None (default) and coefficient==0 instead of error

This is up for discussion within the CDB user base, since it may not be the best approach.

Motivation

We need a SCALAR signal_type for various uses (aggregation, CUDB checks, etc.). However, adding it would need a change in the SQL schema (though just a minor one - adding an Enum choice) and client changes. This "effective SCALAR" implementation "workaround" introduces minimal changes only in the client while retaining the same get_signal API, which would return a CDBSignal with signal.data == array(offset), i.e. a scalar with .data.ndim == 0. One can get the contained float value directly e.g. by .data.item(). When using DataArray from cdb_extras.xarray_support instead of CDBSignal one can use signal.item() directly.

This "effective SCALAR" implementation therefore defines (as suggested by @seidl) a SCALAR as: a LINEAR signal with coefficient == 0, i.e. the offset value.

Possible drawbacks and risks to backwards compatibility

This does change the default behavior though a bit. By default n_samples==None if it is unspecified, which for LINEAR signals simply raises an error. After this change the error will be raised only if coefficient !=0 (thanks to the helpful suggestion by @seidl). However, this seems very unlikely for a signal serving as a LINEAR axis. Therefore, the possibility of "accidentally" using a "constant offset LINEAR axis as a SCALAR" appears to be mitigated beyond reasonble doubt.

Alternative approaches

One can of course use n_samples=1 directly in get_signal once !14 (merged) is merged. But that makes the API less convenient to use, since one has to remember to use this keyword argument and helper libraries and user functions/applications built on top of pyCDB may require changes for this argument to be passed. For instance, with the Shot helper class from cdb_extras and/or cdb_helpers by @seidl one would have to specify shot('signal_name', n_samples=1) instead of shot['signal_name].

A shortcut get_scalar shortcut wrapper which would call get_signal with n_samples=1 could be introduced, but that would likely lead to possibly even more significant changes in existing dependent code.

Another option would be to implement an actual SCALAR signal type, but that would break compatibility with older versions of clients (which are not aware of this type) and in other languages where it might be harder to introduce the necessary changes (e.g. the Matlab client).