In case of remote process exit even when some messages are still
waiting, vchan connection can be already closed. If we try to send some
data in this case (for example stdout of local process), there will be
an error, which will terminate qrexec-client-vm/qrexec-agent child. So
first check vchan data (where could be MSG_EXIT_CODE queued) , then
local process.
There is still some race condition in this code - remote process could
exit just after we check vchan, but before we send some data. But this
is much less probable and in the worst case we only loose remote process
exit code.
Child process can request to use single socket for both stdin and
stdout by sending SIGUSR1 signal. If it does so twice or more, previous
code broke the connection by closing the socket.
This doesn't cover all the cases, because local process could want to
receive that value (currently it cant), but I can't think of any simple,
*compatible* way to pass it there.
This way qrexec-client-vm will have much more information, at least:
- will know whether the service call was accepted or refused
- potentially will know remote process exit code
This commit implements the first point - the local process will not be
started if service call was refused.
Move (qrexec-agent version of) do_exec to qrexec-agent.c, move
handle_handshake to qrexec-agent-data.c (common to all agent binaries).
Fix indentation (tabs -> spaces).
The main advantage is possible use of single socket for both stdin and
stdout. This is strictly required for using USBIP over qrexec.
For compatibility qrexec still creates three socket pairs (instead of
pipes) for stdin/out/err respectively. When qrexec-agent receives
SIGUSR1, it will close stdout socket and use stdin socket for both
directions.
Some additional work is needed here to actually allow child process to
send that signal - qrexec is running as root, but child as "user" in
most cases.
