Clear up confusion between FLOW close, shutdown

[djs55]

The Unix API has

• close: means to release all resources and drop in-flight data
• shutdown_write: means to signal EOF to the remote, while the connection stays up and data can be read
• shutdown_read: means to locally ignore any more pending reads

while the Mirage API was recently clarified to follow the (sensible) behaviour of the tcpip stack:

• close: means to signal EOF to the remote (and it provides a thread which allows handshaking with a close sent from the other end)

The Mirage tcpip stack will clean up resources after the close calls have been acknowledged, taking into account TIME_WAIT states etc (like a Unix kernel would). There is no "socket" "file descriptor" or "socket buffers" which need to be freed separately by the caller since there is no socket layer.

The current proxy loop has 2 threads, one for each direction which so something like:

• read until Eof
• shutdown_read: this is a bit pointless
• shutdown_write: this sends an Eof to the remote

when both threads have finished the proxy returns, and the caller can release any associated resources by calling close. This misunderstanding has lead to strange implementations.

We should drop the shutdown_read (pointless) and convert the shutdown_write into an asynchronous call to close. This means that implementations other than tcpip which are currently calling functions like Lwt_unix.close in close will need to stop doing this and use some other function (disconnect?) instead.

[hannesm]

we have merged #48 now, which adds a shutdown :)