Sensor: Disable interrupts during critical sections to protect writes to sensor data struct

[ETSells]

Requester: @ETSells

(Non-developer requests only): Is your feature request related to a problem? Please describe.
N/A; future improvement to protect race conditions in ISRs.

Describe the solution you'd like
The layout of sensor dump should be modified. The function should check the IMU, baro, and mag ready flags, and once they're set, it should enter the critical section by disabling interrupts and perform its updates to sensor_data. Alternatively, processing can be performed on a double buffer and this can be copied to the global when complete within a critical section.

Add a wrapper for __disable_irq() & __enable_irq() in common.c.

New sensor.c control flow:

1. Initialize locals
2. Rename sensor_it_imu_baro to something like sensor_get_it_ready. Check imu.c imu_data_ready and mag_data_ready flags and baro.c baro_data_ready flag. If either aren't, busy-wait until timeout. If timeout, return from sensor_data with a sensor_timeout status.
3. If there's no timeout, disable interrupts.
4. Continue with original sensor_dump (copy GPS_DATA, get imu/mag/baro data, perform processing).
5. Re-enable IRQ.
6. Return status.

Describe alternatives you've considered
Original design: During operations that write to SENSOR_DATA sensor_data as well as operations that read sensor_data in ISRs (which can be triggered at any point during execution), we should use synchronization primitives to protect this data. Consider atomic mutexes or the HSEM module in the HAL. You can also use a non-atomic operation that disables and then re-enables interrupts as these are still queued up during the critical section and will be serviced upon re-enablement. The implementation should also provide a plan to yield back to an ISR that was triggered while in the critical section.

This ultimately proves to be too complex. The NVIC can automatically handle any interrupt signals that have come in since the DISABLE_IRQ call, which prevents us from having to create a queue in software.

Additional context

Design for LoRa ISR (current-gen and next-gen):

Points of Contact
Interrupts & Sensor: @ETSells

[butchhartman]

Is the intention to skip the critical section altogether (step 4) when a timeout occurs and go straight to status return? Or should the timeout check only control whether interrupts get disabled?

[ETSells]

Yes, do not disable interrupts if a sensor timeout occurs. If you hit an early-return error condition after you've disabled interrupts, make sure you re-enable them before returning.