Write tests to verify gvisor-tap-vsock works as it should

[lstocchi]

We should test if visor-tap-vsock works as expected.
E.g. check if the ports are actually open, if the data sent and received are the same (from small to big data), ...

[lstocchi]

@evidolob @cfergeau feel free to add some other test ideas to verify it works fine. I still haven't looked deeply at the code so what I wrote came out from a discussion with @gbraad

[cfergeau]

What comes to mind:

#321 is related.
On each platform, we'd want to test enabling/disabling port forwarding from the API, check downloading/uploading, maybe between VM and host, and external data. checking for data corruption would be needed as well (ie run sha1/... on the downloaded/uploaded data).
Maybe the DNS tests could be extended, but there are a few of these already.
Detecting performance regressions would be nice, but this means we always run the same benchmark on the same machine, so it's less convenient to do on the long run.

[evidolob]

As for me is having ability to actual debug tests is crucial, not only the test itself, but gvproxy. It will make troubleshooting process mush easier.

[cfergeau]

See also #357 and #269

[lstocchi]

As for me is having ability to actual debug tests is crucial, not only the test itself, but gvproxy. It will make troubleshooting process mush easier.

Can you please rephrase it? I'm not sure I got it.
What do you do to debug gvproxy atm? Asking as I never do that so trying to understand what are the difficulties and how to make it easier.