spipe stays on read() when remote spiped is terminated

[gperciva]

Was #328, but that patch wasn't successful.

About the connection, @cperciva wrote:

we want the same behaviour as regular (not proxied via spiped) TCP connections -- each direction is shut down independently, so that you can e.g. printf(1) an HTTP request and pipe that into spipe, even though the HTTP response will arrive back long after printf exits (and thus spipe's stdin is EOFed).

Whether we're doing this correctly is an open question, of course. But that's the idea -- an error can shut down the connection in both directions, but EOF only shuts down the connection in one direction.

In this particular case, @cperciva wrote:

Hmm... looking back at the test case, I think it will depend on how the OS handles TCP sockets owned by a process which is being terminated. If it sends a RST then spipe should get a read error and exit; if it sends a FIN then spipe will continue until it tries to send something (at which point it will receive a RST and exit).

IIRC this depends on the SO_LINGER setting and possibly on whether there's any data buffered when the socket is closed.