hive: serve simulation API via proxy container

[fjl]

In order to communicate with the simulator container, hive needs to provide an API listener on the same network as the simulator. The way this is done right now is error-prone. At startup, it tries to figure out the local network interface corresponding to Docker's bridge network and listens there. This works on Linux, sometimes. Quite a few people have run into issues with it.

This PR makes the API communication more portable. To listen for simulator commands, hive launches a 'proxy' container. The proxy is an HTTP server that forwards requests to hive via its stdout/stdin streams. Hive also delegates container liveness checks to the proxy, because those checks also require connectivity on the Docker network.

Overall, this change has big advantages:

• Hive can once again run on all platforms because it doesn't rely on Docker implementation details anymore.
• Remote docker can be supported with this method, i.e. you can run dockerd in a Linux VM somewhere and push hive workloads to it from another machine running any OS.
• Since hive does not need direct access to the bridge network anymore, we can isolate clients from the Internet in a future change.

[holiman]

Nice!

[holiman]

Shouldn't you remove that log statement too? It's not true any longer (right?)

[fjl]

I need to fix this, just commented these lines to make it compile :)

[fjl]

Aww, I checked this and there is another catch with remote docker that I didn't think about. Hive also needs to talk to the client container to wait for a port to open. We could make the the proxy do that as well, but it's definitely a non-trivial complexity increase.