PHD: use stty to widen the effective terminal for Linux guests

[gjcolombo]

All of PHD's supported Linux guests' serial console drivers assume by default that they are writing to an 80-character-wide terminal. This breaks calls to run_shell_commands that are longer than 80 characters, because guests will insert extra spaces and carriage returns to deal with terminal wrapping. Suppress this by adding an stty command to these guests' login sequences that tells them the terminal is 10,000 characters wide. Add a framework test to validate this.

The new test also works (with no additional changes) for Windows Server
2022. It won't currently work with Server 2016 or 2019, which use the 80x24 terminal backend, so skip this test on these OSes (and add an affordance that allows a test to ask the framework for the default guest OS adapter without actually setting up any VM configuration).

With this change, the boot order tests' run_long_command function is obsolete, so remove it.

Finally, tweak phd_skip! so that it can take an arbitrary token sequence as an argument instead of only taking a string literal. This allows the use of format! in a skip macro.

Tested by running this test with all supported guest OS flavors, running the boot order tests on Alpine and Debian 11, and running a full PHD test suite against Debian 11.

Related to #773 (but doesn't totally fix it, since earlier Windows Server versions still need some work).

[iximeow]

hurray! thanks for this.

[iximeow]

amazing

[dancrossnyc]

Just FYI, something that Ixi and I discovered at OxCon is that stty rows 0 will set the terminal to the max permissible width (not that 10,000 isn't acceptably large for any reasonable output). I'm afraid terminal types are a slightly reddish-brown herring; they were only relevant in so far as being useful for setting the initial terminal width at login).

[iximeow]

i'd had it in my head that we also found stty rows 0 didn't actually change the terminal width in some case, but now you have me questioning my memory. i don't recall if that was the case (maybe Alpine?), or if it was a different stty operation that had an Alpine/other split, or if i was fully munging my memory of trying to configure Windows terminal dimensions into this.

if it was me misremembering the Windows part of this, Greg also showed me that we're already doing an equivalent for Windows Server 2022 with mode con .... there was definitely a period i thought stty was interesting but not great here because it would be an unfortunate wrinkle if we could only handle long lines on Linuxes 😁