fix(bench): retry shell wake writes and require pymavlink >= 2.4.42

[mrpollo]

Follow-up to the release/1.17 run in #27840. Digging into that log, the shell failures are not the 5s-vs-8.8s boot timing suggested there: preflight opened the same shell seconds after the flash boot, reboot_loop passed the identical 5s open 10/10, and flight_mission failed its probe moments after reboot_loop had just verified the shell on the same boot. The pattern is that the session immediately following a closed one fails, meaning the single wake write gets consumed before the firmware nsh pipes are reading, and no amount of waiting recovers a dropped write.

• MavlinkShell.open() now re-sends its newline plus sentinel wake write every second until the deadline, and stale BENCHOPEN echoes are stripped from subsequent command output. The timeout hardcoded at every call site is now a single px4bench.SHELL_OPEN_TIMEOUT (10s).
• pymavlink 2.4.42 is the first release shipping the mavftp module, so the floor is raised in pyproject.toml, Tools/setup/requirements.txt and the README, and the import is guarded in px4bench.ftp so an old install prints an upgrade hint instead of the raw traceback seen in the issue.
• The param_exists failure now reports the downloaded count and that the autopilot lists used params only. SDLOG_UTC_OFFSET does exist on release/1.17; the real anomaly in that run was a 19-param download (plus heartbeats from system 0), which points at a degraded MAVLink session, not a missing parameter.

Verified with a mock SERIAL_CONTROL endpoint that drops writes for 2.5s: the old single-write open fails, the retrying open succeeds, and the timeout path stays bounded. The missing-mavftp path was tested by blocking the module import.

@farhangnaderi could you re-run the suite from this branch against your 1.17 FMUv6X-RT bench? boot_health, flight_mission and log_transfer should now pass or at least fail with a clearer story. If param_stress still reports a tiny download, please grab param status and mavlink status from the nsh console on that boot; the 19-param set and the sysid 0 heartbeats are worth their own investigation.

[farhangnaderi]

I re-ran the suite from this branch against the same 1.17 FMUv6X-RT bench (same firmware, v1.17.0-6-g6737fe1c37), with pymavlink upgraded to 2.4.49. Results are as below:

TEST            STATUS   TIME(s)  DETAIL
----------------------------------------------------------------------
boot_health     PASS         5.7
param_stress    FAIL         2.2  exit code 1
mission_stress  PASS        10.1
storage_stress  PASS        11.8
log_transfer    PASS        29.1
reboot_loop     PASS        91.2
flight_mission  SKIP         2.1  skipped by the test (see its output above)
----------------------------------------------------------------------
5 passed, 1 failed, 1 skipped

param status on the board shows: 1135/2034 (used/total) params. So it's not a missing-parameter problem I suppose.

I first suspected USB CDC packet loss (mavlink status did show a rough rx-loss number on that instance), but that theory doesn't hold up: I reproduced px4bench.connect()'s exact code path standalone and the real mechanism came out to be component addressing.

This board heartbeats from two components on the same sysid:

srcSystem=1 srcComponent=1   type=2  autopilot=12 (PX4)              <- the real autopilot
srcSystem=1 srcComponent=236 type=34 autopilot=8  (MAV_AUTOPILOT_INVALID)  <- some other onboard component

Possible fix: px4bench.connect() should explicitly resolve and pin target_component to the heartbeat where autopilot != MAV_AUTOPILOT_INVALID (normally compid=1), instead of leaving it at pymavlink's default broadcast 0, and downstream param/mission calls should use that pinned target.