with the goal to make it more clear and the error only appear when
armed but every time the running task doesn't actually match
the mapping inside the start_flight_task() function.
Fixes a regression from 8bae4e5c0e29f70d5d1d2427ffdef97092be939c, where
the orbit flight task wasn't an extra task (flight_tasks_to_add) anymore
and therefore the command handling wasn't generated.
There was a race condition that could cause several outcomes. The most severe
was that flight_mode_manager gets the command, switches to orbit and then
in the next iteration switches back because commander did not change
nav_state yet. When commander then switches, flight_mode_manager would still
be in the old mode.
This is prevented by storing the command (allowing it to arrive before or
after mode switch), and then apply it after the switch happens.
Remove the entire external yaw handler, dynamic memory allocation,
pointer passing logic. Directly instanciate the weather vane instance
in the flight tasks that support it.
This was only handled outside because FlightTaks lived in the
multicopter position controller which produces the data that was
needed but now it doesn't make sense anymore to handle this
subscription separately.
It's better to have it inside the base task to have the data available
on task activation sucht that e.g. Altitude mode can take over smoothly
from Position mode.
Moving the command handling to a separate function that gets called
whenever a vehicle command is available to always react on commands
and not just when already a task is running.
This solves e.g. commanding an Orbit when in Staibilized.
- parameter updates can be quite expensive because they trigger nearly all modules to reload all of their parameters immediately
- limit modules from updating faster than once per second
