or receiving a command that we need to handle. This makes sure that we
don't drop commands, when the output mode is set to mavlink (in that case
the input topic is rate-limited, and each input change results in a
vehicle_command publication, which results in queueing up orb items if we
get vehicle_commands from other sources too).

It causes missed input changes.
This reverts 73d23742.

This reverts commit b7404ad6.

The way the broadcast IP is currently fetched is by sending an ioctl()
request. The limitation of this is that the broadcast address may not
be set on the network interface (more specifically, it is usually not
set in docker containers). In those cases, it results in the broadcast
address becoming 0.0.0.0, which is not valid [1].

This fix uses the network IP and the netmask to compute the directed
broadcast address. This should be more reliable, as both of those are
always set on the network interface.

[1]: https://tools.ietf.org/html/rfc1122, section 3.2.1.3 (a)

* Cygwin: repaired NuttX build after 1f63d858
all the NuttX specific WINTOOL define handling was skiped in cmake Make.defs generation
The Nuttx build is makfile based and needs its cygwin treatment

Additionally the ${PX4_SOURCE_DIR}/src/include which was added through cmake needs path conversion

The two root causes for the special handling are:
- ARM GCC for Windows doesn't support cygwin paths passed as an argument
  so they need to be either relative or converted via cypath tool
- Symbolic links are totally different under Windows and because NuttX uses them extensively
  it has special handling scripts that need to be fed with the correct defines

* Cygwin: NuttX include paths all converted in Make.defs.in

differentiate between WINTOOL define (MSYS & cygwin) and cygwin using uname command:
- MSYS needs symbolic link handling for ARM GCC but no path conversion
- Cygwin needs both

This fixes the case where a topic instance is already subscribed, and
advertised later. The subscriber will create the DeviceNode with default
priority, and the advertiser will just use the existing DeviceNode,
without updating to the requested priority.

This fixes the case where a new gimbal input gets lost in the output
throttling.

This is required because an input is potentially set only once and
then not computed again. In the failure case, control_data is set
to nullptr in subsequent calls and therefore not used for the output
calculation ever.

Let's just hardcode 0 because we don't want to include the mavlink
headers just for this.

This resolves the case where a gimbal command assembled by
QGroundControl is rejected because the component id is set to 0 (for
all) and the component id of the vehicle is e.g. 1.

* add more logging to help with #8556
* log subscribed topics on mission start and test exit (pass or fail)
* use mavlink enums everywhere to avoid maintaining dictionary mappings and to have readable values
* log when the FCU advances to next mission item without satisfying the position reached offset/radius
* some renaming for readability
* log more state value changes (connected and MAV_STATUS)

Avoids ending up with huge log directories.

plus some param alphabetic reordering

Align the way motor output is computed with the model used in the mixer generation script.
previous:
`out = (roll_gain*roll + pitch_gain*pitch + yaw_gain*yaw + thrust)*out_gain`
new:
`out = roll_gain*roll + pitch_gain*pitch + yaw_gain*yaw + thrust_gain*thrust`
which is the standard matrix*vector multiplication.

This commit has 0 effect on symmetric platforms (i.e. most) as thrust_gain==1 on these platforms.
On asymmetric platform --where some thrust_gain are lower than 1-- the previous formulation resulted in coupling between thrust and other axes.

fixes #8628

The geometry was previously quad_deadcat in which front motors are closer to CG and thus more loaded in hover.
quad_wide is the same geometry as quad_deadcat except the CG is centered so all motors are loaded equally.
Flight logs on IRIS with deadcat mixer showed that
- all motors are equally loaded during hover (actuator_outputs 0 to 3 have similar values)
- a negative pitch offset is building up soon after takeoff (visible in actuator_controls)

- Missing get_sync() in verify function
- Allow some time to reboot before closing the serial port
  (closing the serial port drives TX low)