OD Process shall support azimuth and elevation data, and JIT filtering of measurement types

[ChristopherRabotin]

High level description

At the moment, OD only support range and Doppler measurement, simultaneous or not. In practice, especially in LEOP, we may want to use azimuth and elevation data to quickly converge on a valid solution. Moreover, in practice, a tracking data provider may not always align the range, Doppler, and angle data at the same epoch. Hence, this change should ensure that each participant in an ODP can be configured to support either of the supported measurements at runtime without requiring a rebuild.

Requirements

• The ODP must support running with azimuth and elevation data as well. These are currently validated in ANISE, https://docs.rs/anise/latest/anise/almanac/struct.Almanac.html#method.azimuth_elevation_range_sez .
• The ODP must support filtering out this measurement type

Test plans

Best here is probably to build a new example which generates all AER data for each participant, and analyzes how each data kind affects the OD results.

Design

This will most likely lead to a decently large refactoring. Specifically, each ground station will need to specify whether it supports a given measurement type. Then, the data read may be nullable (so it must be nullable in the exported data frame). If it's null, or if that participant does not support this measurement type, then the associated row/column of the sensitivity matrix must be nulled as well. This change will likely simplify the trait bounds for the ODP structure, which is why it must be done before version 2.0.0 is stabilized.