AP_ADSB: uAvionix Transponder Status V3
+ Current version of ping200X sends the v1 status message periodically and the v3 status message in response to the transponder control message, so ardupilot needs to handle both gracefully; version 1 and version 3 are very different in structure and naively assuming one version over another will cause errors.
AP_ADSB: Process additional xpdr status v3 fields
AP_ADSB: Send GCS xpdr status at least every 10s
AP_ADSB: Send ping200X estimated HPL
+ When AP sends the ping200X the GPS data GDL90 message, it needs to provide a valid HPL for the ping200X to report a valid NIC.
AP_ADSB: Don't send unsolicited transponder status
AP_ADSB: Better initialization of xpdr id/config
AP_ADSB: Better initialization of frontend status
AP_ADSB: Suggestions from review
Lua opens scripts to load them into memory, then the logger opens them
after to stream them into the dataflash log. When loading multiple large
Lua scripts from ROMFS, decompression takes a significant amount of
time. This creates the opportunity for the Lua interpreter and logging
threads to both be inside `AP_Filesystem_ROMFS::open()` decompressing a
file.
If this happens, the function can return the same `fd` for two different
calls as the `fd` is chosen before decompression starts, but only marked
as being used after that finishes. The read pointers then stomp on each
other, so Lua loads garbled scripts (usually resulting in a syntax
error) and the logger dumps garbled data.
Fix the issue by locking before searching for a free record (or marking
a record as free). Apply the same fix to directories as well. This
doesn't protect against using the same `fd`/`dirp` from multiple
threads, but that behavior is to be discouraged anyway and is not the
root cause here.
There are currently issues where the non-.exe-suffixed files can't be
copied into the `artifacts` folder; `cp` claims "File exists".
Previously this worked but the suffix was added by Cygwin so all files
in `artifacts` had a `.exe` suffix anyway.
This is evidently intended, though non-intuitive, behavior:
https://sourceware.org/legacy-ml/cygwin/2009-08/msg00293.html
> On Cygwin, you should avoid having a file "foo" and a file "foo.exe"
> in the same directory at all cost to avoid puzzeling POSIX borderline
> behaviour like this. What you do is essentially in the "not
> supported" class of problems.
> [...] Cygwin does not check for a file "foo", if the name of the file
> is explicitely given as "foo.exe".
Apparently something similar was addressed in PR #20926; the current
code installs files with both suffixes, but that fix contradicts the
info above and now has broken.
This PR changes the code to only install .exe-suffixed files, as opposed
to only non-.exe-suffixed files, which was the behavior before that PR.
