Disconnect during negotiation breaks listener

[jfink2]

Describe the bug
Window 1
$ ./nngcat --sub0 --listen ipc:///tmp/gw --ascii

Window 2
$ ./nngcat --sub0 --listen ipc:///tmp/gw --ascii
Unable to listen on ipc:///tmp/gw: Address in use

Window 3
$ ./nngcat --count=200 -i 1 --pub0 --dial ipc:///tmp/gw --verbose --data "Window 3"

Expected behavior
Window 1 nngcat should print "Window 3"

Actual Behavior
Nothing, Window 1 did not print anything. IF you skip the nngcat in Window 2, Window 1 will print as expected.

To Reproduce
I do have C code that does the same - that's how I discovered, but thought nngcat would be better.

** Environment Details **
nng 1.5.2 running on Centos 7.x, gcc 4.8.5 libnng.a (compiled from source)
nng 1.5.2 running on Xubuntu 20.04, gcc 9.3, libnng.a (compiled from source)

Additional context
N/A

[gdamore]

I confirm this behavior. I'm having a difficult time explaining it since the system calls seem to indicate that I'm doing the right thing (analysis via strace). I will test on other operating systems, perhaps this is a Linux bug.

[gdamore]

Well it happens on macOS as well. So I guess it's something I've botched.

[gdamore]

It might be a bug in the handling of unexpected close -- we attempt to connect to the socket to test for a peer, but don't actually send or receive any data.

[gdamore]

It turns out that this was actually a deeper bug that affected other transports, and could have leaked file descriptors or left the transport unusable if the peer disconnected during negotiation. We basically confused this with the case where the parent socket is closed.

The reason this was bad for IPC is that when we are trying to figure out whether to clean up a conflicting socket, we do a connect without actually doing an I/O. This is meant to be being, but if the remote side isn't expecting it, it can be bad.

The solution is to convert connection ECLOSED to ECONNSHUT if it occurs while trying to negotiate. This affects IPC, TCP, and TLS+TCP.