Avoid unexpected repositions

[tstastny]

Solved Problem

1. Geofence reposition lifetime: when in RTL, the geofence reposition setpoint is ignored (ok, fine) - however, the reposition struct that holds that geofence position is stored until the next flight. If a manual control loss then engages a hold (during RTL delay time), the reposition setpoint is taken for the hold, which may be anywhere else other than the vehicle's current position.. which would be the desired hold position.
2. External reposition commands without a requested mode switch (flag) are silently accepted and can cause unexpected positioning when hold is engaged.

Solution

1. In the loiter activation methods, check the reposition setpoint's timestamp in addition to validity.
2. Don't allow reposition commands without a requested mode switch.

Changelog Entry

For release notes:

Bugfix: Don't allow external reposition commands without a mode switch, and ensure old reposition commands are not erroneously set.

Alternatives

Real solution is not sharing the reposition struct between multiple modes, and not reusing loiter mode for goto and hold.

Test coverage

• used libmav to send a reposition command without the modeswitch bit.. it rejects now
• test case:
  • unplug manual control
  • let the multicopter rtl with geo fence boundary set near home
  • geo fence sets reposition struct somewhere along the path towards home (but rtl ignores)
  • vehicle lands, disarms
  • arm and takeoff again in manual
  • unplug manual control
  • rtl ensues
  • the rtl hold delay before returning to home is correctly set to the vehicle's current position (not the previously set reposition struct from last flight)