core: frontend: Allow user to provide arguments for ArduSub executable

[Shono1]

Current behaviour

The Ardusub executable provides users with a myriad of flags and options, however BlueOS' ardupilot-manager service runs Ardusub with hard-coded arguments.

Expected or desired behaviour

The user should be able to somehow provide their own arguments to the ArduPilot executable. This would allow the user to define parameters such as the GPS starting location (--home), simulation model (--model), SITL framerate (--rate), and simulator ports.

On the backend, I think it would make most sense to store these parameters in the settings.json (--model is already stored here). Other backend changes would include:

• Detecting and communicating ArduPilot crashes. Part of what made #3419 tricky to debug was that it was not readily apparent that ArduPilot had failed to launch. If users will be providing their own arguments, BlueOS should let them know if their process failed and why.
• Reloading settings in ardupilot_manager.py after each change to the settings or before restarting the Ardupilot process
• API endpoint for modifying Ardupilot arguments
• Storage for default arguments

I'd also make a method for launching ArduPilot instead of the individual popens in the start_sitl and start_linux_board methods. I haven't confirmed this, but I think the current implementation creates a bit of a visual bug when using SITL firmware. The serial port configuration shows, but the configuration isn't ever included in the popen call in start_sitl. I think this means the user can modify the serial port configuration, but it won't do anything.

The frontend could be handled in a few different ways:

1. The simplest way would be to provide no frontend and have the user just mutate settings.json with the file explorer. This works, though is highly inelegant. If this route is taken, it should be documented in-app and in the Advanced Usage guide.
2. A more elegant solution would be to provide users a "build your own dictionary" interface, where they can provide the names and values of the arguments they would like to provide. Default arguments should show up as pre-populated fields.

3. The most user friendly (though likely hardest to maintain and least flexible development-wise) solution would be to provide a validated input field for every single argument. This would be very difficult to maintain for firmware versions with different options, and seems like overkill for something that will likely be a "Pirate Mode" feature.

I'll be developing at least the backend of this next week, as I need it for my simulation architecture. No pressure to pull this if it's considered too niche for the main application. If anyone has suggestions or amendments I will gladly take them into account.

Prerequisites

• [x] I have checked to make sure that a similar request has not already been filed or fixed.

[ES-Alexander]

Hi @Shono1, thanks for the suggestion :-)

This seems quite reasonable, and I think it makes sense to include as a feature in the autopilot manager service.

A frontend option between 1 and 2 could be to include a JSON viewer/editor (like is already done for the settings of the installed Extensions). That said, a key-value pair builder (as you suggested in 2) could be quite nice as a quality of life feature.

Agreed that this should only be visible in Pirate mode, since most users won't need it, and could be confused by it.