- set integral states and setpoint of reference state to 0
- set thrust to NAN if it will be computed from position and velocity control

obstacle_distance: update distances description according to latest obstacle_distance mavlink message

added unseal() and seal() around write_flash() for enabling/disabling cell undervoltage, we found out today this wasn't being written because that address is in protected flash

commented out something causing trouble with CI, it is in an unused function but I'd like to keep the comment there as a reference for future development effort

* lis3mdl: Report calibration successful when starting with -C option
* lis3mdl: Use PX4_OK, PX4_ERROR for return value / orb_unadvertise
* Fixes #10740

This change has two effects:
1. We always acknowledge a param write no matter if the value was
   actually changed or not. This is according to the spec:
   https://mavlink.io/en/services/parameter.html#write-parameters
2. This fixes the bug where int32 parameters were not actually acked
   because the memory of the param value was casted directly to float
   and then compared. In the case of a int32 parameter set from 0 to 1
   it would mean that the cast to float of the memory representation
   was still 0 and therefore it was assumed to be "no change" and the
   ack was omitted.

fixed a problem where the heater was getting stuck on. This was due to the next on time being calculated as a negative time, thus causing it to not get rescheduled in the work_queue. Also removed some includes in the header file

Required on RPi, the default seems to be too high.

The rate controller is now run directly after a gyro publication, and
as soon as it publishes the actuator controls, the output driver (fmu/...)
runs.

Test on a Pixracer:
Reduces fmu control latency from 219us to 134us.
If we run the rate controller last (same order as before, just increase
the prio), the latency is 201us.

CPU load is unchanged.

The drawback is that the attitude to rate setpoint generation is delayed
by one cycle (4ms), but it will be reduced to 1ms as soon as we run at
1kHz.

This will allow to run the rate controller faster than the attitude
controller.

2ms is not enough to run at 1kHz

improves readability & reduces duplicated code