Propolis could infer if boot settings didn't work

EDK2 prints, to the console, what boot options are being tried and if they've failed. we could adjust it to print that to the QEMU debug port as well, which we could watch for messages about Boot0001 and friends listed in an explicit boot order (if there is one) being tried and failed. that would at least be able to elevate https://github.com/oxidecomputer/propolis/issues/1181 into something Propolis could error!() about - otherwise the guest's state is a total unknown. as things stand, propolis-server's log really cannot give you much of an idea of if a guest booted "normally" or not. in the future that could become an ireport that makes its way out to some indicator in the console that an instance is probably in a bad state!

the problem here is that input from the QEMU debug port must be considered fully untrusted. guests could emit whatever they want to that port after booting. a bug in EDK2 allowing a crafted guest image to do bad things means we can't really trust anything "before" a guest booted either. this is all only informative and guessing at the guest's possible state, at best, and cannot be considered authoritative at all.

but if we could take a guess that we've tried and failed to boot the user's requested boot options, and instead failed into the UEFI shell, that'd be really helpful!

(this would have helped with the logs in https://github.com/oxidecomputer/propolis/issues/1181 just a smidge..)

Start by tracing how propolis-server receives and logs data from the QEMU debug port, then review the EDK2 boot messages described here and the failure logs in issue 1181. Done means Propolis can cautiously recognize failed explicit boot options or a UEFI shell fallback and expose that state as an informative error or report, while treating all debug-port input as untrusted.