- sync posix_sitl_default and px4fmu-v4pro/v5 with fmu-v3
 - fixes #6667

In SITL, logging rate reduces from 70kB/s to 45kB/s.

Now AeroFC is making use of both flash memory banks so it need this
workaround.

backport 3cd66af889b42b036d6c9d88e067fc3b8abbdb2a and pr 258

   Applies to STM32F4 and STM32F7

   STM32, STM32 F7, and STM32 L4: Clone Freddie Chopin's I2C change to similar STM32 I2C drivers.

   Save elapsed time before handling I2C in stm32_i2c_sem_waitstop()
   This patch follows the same logic as in previous fix to
   stm32_i2c_sem_waitdone().
   It is possible that a context switch occurs after I2C registers are read
   but before elapsed time is saved in stm32_i2c_sem_waitstop(). It is then
   possible that the registers were read only once with "elapsed time"
   equal 0. When scheduler resumes this thread it is quite possible that
   now "elapsed time" will be well above timeout threshold. In that case
   the function returns and reports a timeout, even though the registers
   were not read "recently".
   Fix this by inverting the order of operations in the loop - save elapsed
   time before reading registers. This way a context switch anywhere in the
   loop will not cause an erroneous "timeout" error.

   5a6d95dd9f051be548a8d2378aaef75f0a1ba5e1 and ee5ae3a57dbbe835584f164c956e0374da1ed2eb

   Applies to STM32F4 and STM32F7

   Save elapsed time before handling I2C in stm32_i2c_sem_waitdone()
   It is possible that a context switch occurs after stm32_i2c_isr() call
   but before elapsed time is saved in stm32_i2c_sem_waitdone(). It is then
   possible that the handling code was executed only once with "elapsed
   time" equal 0. When scheduler resumes this thread it is quite possible
   that now "elapsed time" will be well above timeout threshold. In that
   case the function returns and reports a timeout, even though the
   handling code was not executed "recently".
   Fix this by inverting the order of operations in the loop - save elapsed
  time before handling I2C. This way a context switch anywhere in the loop
  will not cause an erroneous "timeout" error.

This backend will keep all updated data in RAM and
persist the data between reboots using flash memory.

Using only flash memory would result in a slow backend that
would decrease the lifetime of the flash memory, using both
we can reduce the several cycles of erase & write into flash
and keep the performance of the backend almost as fast
as the RAM only backend.

Note: Do not use this backend on a sector from the same flash memory
bank as the memory bank that STM32 read instructions or it can block
the CPU from fetching instructions from flash during the erase and
write operations and cause your drone crash.

So flash sector of 64Kbyes and 128Kbytes can also be used.

Also having just a boolean to track if backend is running.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

if there is not, the process on the other end of the pipe will just block.
This improves reliability over slow links.

There is no need to wait, and it would be the wrong way of doing
startup synchronization.

This makes sure the px4 process does not hang when Ctrl-C is pressed
during startup.

The initialization code is redundant and incomplete (only the first sensor
is done). I verified that all drivers already set this on startup.
For the mags, they all set their maximum supported update rate.
For the baro, the call can silently fail, as for example the MS5611 which
does not support 150Hz update. But it also sets the maximum in
initialization.

Tested on Pixhawk & pixracer.

In HIL mode we do not start the sensors anymore, so this is not needed.

Also it did not work (I did not try to find the reason, just noticed the
sensors kept publishing in HIL mode)