enable serial terminal interaction

[rcooke-warwick]

PR to enable executeCommandInHostOs() in tests to use serial terminal as an option, instead of ssh

The main use cases were:

• in cases where we have a connectivity issue, we have no way into the DUT, this would allow for that. Currently we jsut get "could not reoslve xyz.local" and we can't determine if the DUT didn't boot or there was a connection issue
• we will actually be able to do the dev/prod serial tests (we're not at the moment)
• will allow us to do tests where we disrupt the network connectivity - e.g to test the NM recovery mechanism alex and zahari were discussing

Notes on implementation:

• the "execute this command on serial terminal at device /dev/* and collect the exit code and response" is implemented here: https://www.npmjs.com/package/@balena/node-serial-terminal/v/0.0.2-build-ryan-initial-commit-0150dd382d2567fd3ad5d5203301918b27a51a60-1. It deals with the login prompts, retries, and managing the shell. This was generic functionality that's potentially useful elsewhere, so its a package
• on the qemu worker, I had to enable the -serial pty option to make qemu output the devices serial port to a pseudo terminal. The resulting /dev/pts/* device is allocated at runtime, so I had to also check and parse the stdout from qemu-system to extract it
• for autokit, env vars are used at the moment to denote the serial device name, baudrate etc.
• the serial device that is used is only visible in the worker container. So to run commands over it from the tests in the core container, the only solution I could come up with was to use a new endpoint - which I don't love. But using socat to forward the serial port over the network is another option, but requires more socat hopping and further mess - I'm open to trying it if people think its worth the effort. Ultimately I think worker and core will be merged at some point, so might not be worth jumping through those hoops
• right now it only works with root user in the DUT serial terminal.
• There is a PR that needs to be made to core, to the executeCommandInHostOS function to allow for it to use serial instead of ssh as the communication channel, will update this when its made

Change-type: patch

[klutchell]

No objections from me. What is the main use case or benefit of adding this?

[alexgg]

@rcooke-warwick how is the caller to executeCommandInHostOs() choosing channel (ssh/serial)?

[rcooke-warwick]

sorry @alexgg @klutchell I had opened this PR the other week just to test flowzone out (it was during that point where alexes PR got caught in the required checks deadlock) it wasn't ready for a review

I hadn't looked at it since then, but will come back to it now. The main use cases were:

• in cases where we have a connectivity issue, we have no way into the DUT, this would allow for that. Currently we jsut get "could not reoslve xyz.local" and we can't determine if the DUT didn't boot or there was a connection issue
• we will actually be able to do the dev/prod serial tests (we're not at the moment)
• will allow us to do tests where we disrupt the network connectivity - e.g to test the NM recovery mechanism alex and zahari were discussing

[klutchell]

Sounds good to me, if it's working for you!

[rcooke-warwick]

@balena-ci I self-certify!