Refactor: instruments have sensors

[j-atkins]

Overview

This PR centralises/abstracts instrument sensor/variable sampling logic so that each instrument declares which sensors it carries (e.g. TEMPERATURE, SALINITY, VELOCITY). Users can configure which sensors are active for each instrument in the expedition YAML.

This helps pave the way for easy addition of BGC sensors to the Argo float in a future PR (#234), and consolidation of CTD + CTD_BGC into a single instrument (#260) with a combined sensor allowlist. Also makes it straightforward to add new sensors to any instrument in the future (e.g., #312, #313), and streamlines them process for developers to add new instruments (i.e. #237)

Major changes

• sensors.py in instruments/ defines the SensorType class and per-instrument allowlists (so that there is control over which sensors each instrument supports and users cannot configure unsupported sensors).
• New SensorConfig pydantic model and sensors field in every instrument config in expedition.py.
• New SensorRegistry in utils.py that maps each SensorType to its FieldSet key, Copernicus variable name, category (phys/bgc), and Parcels particle variable name(s).
  • Per-instrument parcticle classes are now built dynamically at runtime based on which sensors are active, but the fixed/mechanical variables are still hard-coded in the instrument files, e.g. cycle_phase for Argo Floats.

API change

As mentioned above, the instruments config section of the expedition YAML now has a sensors list field, where users specify which sensors are active. For example, below the CTD is configured to sample TEMPERATURE and SALINITY:

ctd_config:
  stationkeeping_time_minutes: 50
  min_depth_meter: -11
  max_depth_meter: -2000
  sensors:
    - TEMPERATURE
    - SALINITY

• If the sensors list is omitted, it default to all valid sensors for that instrument.
• By using allowlists for each instrument, it will not allow non-sensical sensor combinations (e.g. BGC sensors on an ADCP).
• Will also not allow an empty sensor list, at least one sensor must be active.

Additional change

• Argo Float sampling kernels have been separated from the vertical-movement kernel, making it easier to add BGC sensors in a future PR.

Follow-up PRs

• The plan CLI tool will need updating to account for sensor configuration options. Currently not broken but doesn't give option to configure sensors. (New issue to be opened)
• Docs update to clearly communicate which sensors each instrument accepts, and how to configure them in either the plan tool or the expedition YAML. (New issue to be opened)
• Merge CTD + CTD_BGC into a single instrument. (Unify CTD and CTD_BGC to one instrument #260)
• Add BGC sampling to Argo Floats (New ARGO_BGC instrument #234)

Tests

• Update existing tests and add new tests to cover new sensor logic

[j-atkins]

I have addressed various comments from the first round of review on this PR. See below for a list of main changes:

• Renamed all _*_FIXED_VARIABLES lists to _*_NONSENSOR_VARIABLES
• Renamed _SensorMeta to _Sensor, added type_: SensorType as a field so each sensor object is self-describing, and moved the class + SENSOR_REGISTRY from utils.py into sensors.py
• New _InstrumentConfigMixin in expedition.py defines shared methods that can be flexibly inherited across the InstrumentConfig models, addresses duplication flagged.
  • Note, though, also that this logic has been extended to other preexisting datetime related parts of the InstrumetConfigs, e.g. minutes and lifetime params (so this is some 'bonus' refactoring).
  • The tests associated with each method are maintained and a new test added to test_expedition.py to check that all InstrumentConfig models inherit from the mixin.
• Instrument subclasses (e.g. CTDInstrument) must now define sensor_kernel dictionary to map the sensor types to the relevant sampling kernels as a class attribute. This is checked by the Instrument base class and also a test added to test_base.py. Means the allowlists for different sensor types are now explicitly defined and managed within each instrument class, which is nice for further centralising instrument characteristics and behaviours.