Keep relaying after a connection the host end cannot serve

[MayCXC]

Summary

A guest connection is served by opening one to the socket the relay was given, and that open fails whenever nothing accepts there any more: the process holding it exited, the socket was replaced, or the path names something that is no longer listening. The failure left the accept loop, so the listener stopped and the relay served nothing further. The socket stayed where it was, so every later caller found it, connected, and waited on a relay that had gone. A caller met neither the service nor the refusal that would have sent it to whatever it does without one.

Fail the connection instead of the relay, and close the connection so the caller is told. A connect that never reaches the relay closes its own socket on the way out rather than leaving the descriptor behind.

Closes #867.

Motivation and Context

The lifetime of the thing being relayed to is not the lifetime of the relay. A host service that restarts is ordinary, and the relay is meant to outlive it, but one failed open ended the listener permanently. The symptom is bad in a particular way: a hang rather than a refusal, so the caller waits instead of falling back.

Related

#841 touches this file too, for a different fault: when outbound relays start relative to the container's mount namespace, and resolving guest paths through /proc/<pid>/root. The two changes are independent and will want a trivial textual merge if both land.

Testing

• swift build and make check clean.
• swift test: 603 tests in 83 suites passed.
• Exercised by hand against the sequence in [Bug]: A socket relay stops serving for good when one connection cannot be served #867: connect, kill the host listener and connect again, restart it and connect a third time. Before the change the third connect hangs; after it, the second is refused and the third is served.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update