Derivation by Mathieu Bresciani:
https://github.com/Auterion/trajectory_generator

- do not set zero throttle during the entire back-transition because otherwise
we need to make the back-transition really short
- added ramping up of throttle setpoint during backtransition to avoid
step inputs
- back-transition ends after back-transition time and not when motors are fully
rotated updwards. previously the vehicle would enter hover mode at high speed
which was not handled well by the mc position controller

Signed-off-by: Roman <bapstroman@gmail.com>

* Add attitude sub to mc_pos_control for yaw usage.

* Initialize pos control _states struct.

* Remove unnecessary init for struct in mc pos ctrl.

* Only use att topic for yaw setting in FlightTask.

Signed-off-by: Roman <bapstroman@gmail.com>

- fsync can be a long blocking operation, so we need to make sure the main
  logger thread does not block during this time, when it tries to aquire
  the mutex
- fixes calling fsync on an invalid file descriptor

 - only used in test routines

 - only SENSOR_POLLRATE_DEFAULT is needed

 - only used in self tests

- set integral states and setpoint of reference state to 0
- set thrust to NAN if it will be computed from position and velocity control

This change has two effects:
1. We always acknowledge a param write no matter if the value was
   actually changed or not. This is according to the spec:
   https://mavlink.io/en/services/parameter.html#write-parameters
2. This fixes the bug where int32 parameters were not actually acked
   because the memory of the param value was casted directly to float
   and then compared. In the case of a int32 parameter set from 0 to 1
   it would mean that the cast to float of the memory representation
   was still 0 and therefore it was assumed to be "no change" and the
   ack was omitted.

The rate controller is now run directly after a gyro publication, and
as soon as it publishes the actuator controls, the output driver (fmu/...)
runs.

Test on a Pixracer:
Reduces fmu control latency from 219us to 134us.
If we run the rate controller last (same order as before, just increase
the prio), the latency is 201us.

CPU load is unchanged.

The drawback is that the attitude to rate setpoint generation is delayed
by one cycle (4ms), but it will be reduced to 1ms as soon as we run at
1kHz.

This will allow to run the rate controller faster than the attitude
controller.

2ms is not enough to run at 1kHz

improves readability & reduces duplicated code