Handoff gets stuck if it cannot connect to destination #3
Description
Because we start the processes/threads to start pulling data from QEMU and deduping/compressing it before we attempt to open a connection to the stream-server on the destination node, if there is an issue connecting, the VM is now in an inconsistent state where it cannot recover. Dirty state is being read from QEMU, being deduped and compressed, but it is never shipped to the destination. You cannot terminate the VM in virt-manager either. It seems that we need to attempt the connection to the destination prior to instantiating the subprocesses and in fact block until we are successfully connect. If we cannot connect, then we should gracefully return an error to the client and act as though no handoff signal was received. An easy way to reproduce this is to have a typo in the destination when performing handoff, for example, us-west.nepehele.findcloudlet.org. The stream-client will attempt to connect 5 times over 10 seconds to the destination, but because that is not a valid hostname it will fail.