This reverts commit 79abec9038.
The problem will not be applicable in new protocol, where vchan
connection is directly between VMs, so there is no longer two connected
qrexec-clients - always one end of data flow in qrexec-client is vchan,
which provide information about amount of data to read or buffer
space to write (lack of the later in case of pipes was a cause of the
original problem).
When VM-VM qrexec service is called, two qrexec-clients are connected in
dom0. If both VMs are sending data simultaneously it can happen that
both qrexec-client processes will call write(2) and none of them will be
reading -> deadlock.
Solve it by handling I/O in two separate threads (one for reading from
VM, another for writing), at any time qrexec-client is ready to accept
data from either direction.
