Don't terminate qvm-run on any SIGCHLD, check if the process we're
waiting for have finished.
Currently the only situation when it's broken is a test (which starts
additional process, whose SIGCHLD may be caught here), but lets do not
assume that much (starting only one process) about environment.
Make it easy to retrieve DeviceInfo object out of DeviceAssignment
object. The only missing piece of information for that is device class,
so add it. Make it optional, as it can be filled on demand when passing
the object through DeviceCollection (either by listing devices, or
attaching/detaching).
This also makes DeviceCollection._device method not needed anymore.
It is supported only from dom0, but it's still useful to have, to save
on simultaneous vchan connections (only waiting for MSG_DATA_EXIT_CODE).
This is especially important for Windows VMs, as qrexec-agent there have
pretty low limit on simultaneous connections (about 20).
Make qvm-run use it.
Since we use qubes.VMShell service now and send requested command on its
stdin, we need to terminate that shell after requested command -
otherwise the service will not terminate automatically waiting for
further input (next commands).
qubesd_call expect "bytes" type. Additionally serialize false value as
empty string (which is treated by python as false value), because
otherwise would be serialized to (non-empty) string, which is true value
in python.
Do not color qvm-run diagnostic messages, but also avoid ANSI control
sequences in logs. While at it, do not print 'Running ...' message when
--pass-io is used.
Most of them are moved from core-admin repository, even if tool is not
implemented yet. Some are generated using skel-manpage.py script.
This way we have complete man pages list, and sphinx will properly
warn/error about inconsistencies.
Allow use StdoutBuffer context manager inside another similar context
manager. This allows running the tests by a test runner which collect
the output using similar trick.
Lets also test basic communication primitives. `mock` python module
makes it _much_ easier, so lets use it also on python2 - requiring
backported version installed.
This differ from main core-admin API, because Admin API do not expose
separate `create_on_disk()`/`clone_disk_files()` functions. When this is
a single operation, `add_new_vm()` cannot be repurposed to clone VM.
