Plane: Mode LoiterAltQLand to reuse same loiter point if available

[magicrub]

Current behavior:

• When switching to mode LoiterAltQLand we set the current location as the center of the loiter.

Problem:

• If we were already performing a loiter then our circle center changes

New/Proposed behavior in this PR:

• When switching to mode LoiterAltQLand, if we were already in a loiter then continue using that same center location point

[magicrub]

Along with PR #25319 this will enable this flight mode to have accurate landings

[IamPete1]

LGTM, had a little play in SITL, a nice improvement.

[tridge]

this could be true in modes like FBWA, cruise etc, would go to the wrong position

[magicrub]

@tridge changed to
const bool already_in_a_loiter = plane.previous_mode->does_auto_navigation() && plane.reached_loiter_target();

Which I think should handle all the cases.
Note, I CAN NOT use the most accurate and direct check plane.loiter.start_time_ms > 0 because it gets set to 0 in set_mode() before _enter() is called. I looked through the code and it looks like moving that set to 0 is probably OK to move to after the _enter() is successful but that has the potential to create some gremlins that aren't worth it. At this point I feel like reached_loiter_target() not being set to zero in the same place is a bug fixing that by setting to zero would break this PR. To globally fix that we would change reached_loiter_target() to return control_mode->does_auto_navigation() && nav_controller->reached_loiter_target(); but that would need some additional testing.

[magicrub]

@Hwurzburg wiki update here ArduPilot/ardupilot_wiki#5499

[magicrub]

This is ready to merge with suggestion(s) from the DevCall applied.

[magicrub]

I wrote this to do millis() checks and it just looked way too cumbersome for what we're wanting out of this. I realized a more straight-forward solution is to just invalidate the state AFTER a mode change so that enter() and _enter() will still get the existing state but after that it's correctly cleared. That's full-proof. If we want something MORE full full-proof that is time based then we should re-work loiter.start_time_ms to be updated appropriately in all modes which would warrant a new/different PR and lots of testing.

stale

[magicrub]

@IamPete1 changes suggested by you from the devcall have been applied. Please re-review

[IamPete1]

I have tested switching into LoiterAltQLand from a mode which is loitering and the point is not moved. I also tested changing to intermediate mode and the point does move.