sensors/vehicle_gps_position: untangle and remove unnecessary state

[dagar]

@JacobCrabill @bresch this is the refactor/cleanup of GPS blending originally from #14447.

NOT TESTED.

This would be a good excuse to add proper testing in SITL for GPS blending and perhaps even restructure the blending logic to make it unit testable.

[dagar]

Relatedly, now that GPS blending has moved to the sensors hub we can think about expanding it slightly for Multi-EKF (#14650).

• SENS_GPS_MODE
  • publish all GPS, publish a specific instance, publish blended, publish highest priority, etc

We also need to add per instance metadata at the sensors level instead of single set of position offsets in EKF2.

• EKF2_GPS_POS_{X,Y,Z} -> SENS_GPS_n_POS_{X,Y,Z} (FYI @CarlOlsson)
• to keep things simple we can pass the position in vehicle_gps_position since the message is low rate (5-20 Hz)
• GPS will need device ids

[bresch]

isn't that useful?

[dagar]

It looks like it was removed back in ekf2, but somehow got lost in the drawn out PR sitting around for 6 months.

8de1f52#diff-72bb106f8fdfef0de0e8174f5b63ad2987bd47a8f07ff445bde40a812c87651e

[dagar]

A lot of the state has been removed, but this is still hard to follow. Let's layout a simple test plan here.

[JacobCrabill]

Just took a brief look through, and seems ok - I'll give myself a TODO to try it out with a couple GPSs on a real board, and capture logs.

[JacobCrabill]

Blending looks good (using dual Here3 GPS units over UAVCAN) (rebased just before testing to ensure the UAVCAN bridge would work):

[JacobCrabill]

@dagar to be clear, all I did for testing was ensure that two sensor_gps publications were combined in a convex combination into the vehicle_gps_position topic; not exactly thorough, but more of a sanity check.

[dagar]

Thanks @JacobCrabill