Fix baro fail-over in GPS hgt mode

[bresch]

When the primary height source is GPS but the GPS data times out, EKF2 switches to baro and makes a reset. However, the _hgt_sensor_offset was not set to 0 and the height reset creates an incorrect jump in the state.

partially fixing PX4/PX4-Autopilot#14677

[priseborough]

The changes look like they should address the issue caused by unnecessary and incorrect application of _hgt_sensor_offset to baro height. We do need to get some test data for the GPS -> baro -> GPS height case. This should be possible in SITL by setting EKF2_HGT_MODE = 1 stopping GPS and then restarting it .

[kamilritz]

You could try to add a test for this. Reproduce the issue in sitl. Convert the ulog to the sensor data format. Replay the data during the test just before the switch to baro. Switch to baro, continue replaying the data for some small amount. And check that the height is closed to the one before the switch.
The same data could then also be used for more extensive change_indication.

[bresch]

Reproduced in SITL:

Shows a jump of 7m

Replayed with this fix:

Jump of 3m only. We still have a small jump because it's a reset and the baro offset doesn't exactly compensate (it's a filtered value). But this should be all right, the reset counter increments, the delta_z is published and should be handled by the setpoint generator.
However, I found that we have a race condition in the handling logic and I'm trying to fix it.

For reference, this is the replay without the fix:

[bresch]

I even got a better one here after going in and out of range aid a few times:
(Original log: https://logs.px4.io/plot_app?log=12da16ef-b98c-47ca-85b5-fdd87aabd09f, note that I fixed the reset on the firmware side, this is why there is no thrust spike despite the height change of 400m)

Replayed with this PR: