The TECS controller belongs really into the ECL (estimation & control library) where we have collected a number of vehicle control systems. It is being replaced by a new implementation of the algorithm, contributed by Paul Riseborough.

Instead of just checking whether the first waypoint is too far away from
home it makes sense to also check between waypoints.
This can prevent
- flyaways due to user errors, or
- catch the corner case where a takeoff waypoint is added to a mission
  and therefore the first waypoint is not too far away, however, the
  subsequent waypoints are still too far away.

Checking with 3Hz for new topics should be fast enough.

flight review now uses vehicle_status & manual_control_setpoint

to avoid dynamic memory allocations & frees (specifically in orb_exists)

If logger is started very early, orb_exists() will fail for a lot of
topics, they will be advertised within the next few seconds.
Logger already dynamically adds subscriptions during logging, but if we
do that before as well, we'll avoid any delays and having to subscribe
to a lot of topics all at once.

To keep track of the configured interval, we store it as negative file
descriptor, until we do the subscription.

This frees up a considerable amount of file descriptors in most use-cases.

Existing users of orb_exists:
- logger (dynamic subscribe to multi-instances)
- mavlink (orb subscription)
- sdlog2
- preflightcheck (check for home_position)
- wait_for_topic shell command (it's not used)
- orb_group_count() (sensors: dynamic sensor addition)

All use-cases benefit from the changed semantics: they are really only
interested if there is a publisher, not another subscriber.

mc_att_control: defualt parameters set maximal acro rates to 2/1.5 turns per second for roll,pitch/yaw

mc_att_control: use expo input for acro mode to allow for high input rates without loosing input sensitivity

we're out of flash again :/

The board id was used as flight id which does not make sense.

arming_state_changed was not set in all places where an arming transition
occurred, for example when calling arm_disarm() from auto-disarm.

We did not notice because the state is published with at least 5 Hz already.

The size in g_per_item_size[item] is the real struct size
+ DM_SECTOR_HDR_SIZE bytes of header and the backend functions were
not taking in care it. So a call to dm_write() with more bytes than
the real struct is allowed, causing corruption in the header of the
next item.

Kudos to jeonghwan-lee for finding it. https://github.com/PX4/Firmware/issues/7927

Adding Sugnan Prabhu as maintainer for Intel Aero.
With great power comes great responsibility!

This is more flexible, allowing a combination of sets.

The default enables the same set & rates as before

DroneCore uses the attitude quaternion, and not the attitude
Euler angles.