fix: correct SCTPConn close logic and add Abort

[gomaja]

Close swapped _fd to -1 and then called SCTPWrite to send SCTP_EOF. SCTPWrite reads the descriptor back through c.fd(), so that write always went to -1 and silently failed — the EOF chunk was never sent.

Rather than reorder it, this removes the write and shuts the socket down directly. Close now performs a graceful shutdown and waits for the peer to acknowledge, falling back to ABORT if it does not respond within the grace period. Without that fallback a peer that has gone away left the association occupying its address, so a later bind failed with EADDRINUSE. The same path is used on the dial and listen error paths, where a plain close() left the socket bound and made the next dial fail the same way.

Also in here:

• Abort() for callers wanting immediate termination with no handshake.
• fd 0 leak. The descriptor guard was fd > 0. Zero is valid — a process that has closed stdin can be handed fd 0 for a socket, and such a connection was never closed at all, leaking it while Close returned EBADF as though nothing had been open. Now fd >= 0.
• Discarded errors. closeSctpSocket ignored every syscall result. The timeout guarantee rests on SO_RCVTIMEO being programmed, so a failure there turned the wait into an unbounded blocking read; those cases now fall back to an immediate abort. The wait read itself is still ignored deliberately — every outcome ends the wait — and that is now stated rather than implied.
• CloseWithTimeout exposes the grace period instead of hardcoding 3s, with both defaults as named constants. A non-positive timeout is equivalent to Abort.
• The timeval is built with syscall.NsecToTimeval; the manual Sec/Usec arithmetic truncated a sub-microsecond timeout to zero, which the kernel reads as "no timeout".

Tests

The fd 0 leak is proven through the public API, not by asserting on internals: a child process closes stdin so the association lands on fd 0, then checks Close both reports success and actually released the descriptor. Reverting the guard to fd > 0 fails both the Close and Abort variants.

Scoped cases cover rebinding after close, an unresponsive peer not holding Close past its timeout, double close returning EBADF, a nil receiver, and concurrency — exactly one of eight racing Close/Abort callers wins the descriptor, and close racing a blocked read or active writer unblocks them. FuzzCloseWithTimeout varies the grace period across the negative, zero and sub-microsecond values (47,800 executions, no failures). TestCloseChurnUnderLoad runs 120 concurrent dial/teardown cycles asserting no descriptor growth.

testdata/ adds a Docker harness and a tshark script, since the difference between the teardown paths is only visible on the wire:

path	observed
Close	SHUTDOWN → SHUTDOWN_ACK → SHUTDOWN_COMPLETE, no ABORT
Abort	one ABORT, no SHUTDOWN
Close, unresponsive peer	ABORT fallback in ~100ms

Notes

The MSG_DONTWAIT change that was previously in this branch has been split out — it alters SCTPWrite's contract for every caller and deserves reviewing on its own.

TestDialUnderChurnReportsEISCONN records a separate dial-side limitation found while fuzzing: SCTPConnect can return EISCONN on a freshly created socket under rapid reconnects. It is documented rather than asserted so it does not become flaky.

CI shows TestStreams failing; it fails the same way on an unmodified master and is untouched here.

[gomaja]

@ishidawataru after the fix, the c.SCTPWrite(nil, info) is returning an error "invalid argument"

I think SCTPWrite can be removed completely from Close.

[gomaja]

This code part "defer" after an error with close is not performing well in dialSCTPExtConfig, specifically when SCTPConnect is returning one of the errors (syscall.EISCONN, syscall.EALREADY, syscall.EINPROGRESS). Mostly syscall.EINPROGRESS.
The close in defer is not completely closing the socket, and the next call of dialSCTPExtConfig is always giving syscall.EADDRINUSE. The issue can be fixed by adding also syscall.Shutdown(sock, syscall.SHUT_RDWR). However, I solved it with a more general close.

defer func() {
		if err != nil {
			syscall.Close(sock)
		}
	}()

[gomaja]

PR ready for review,. Changes have made operation very smooth as previously it was very faulty specifically when the connection sends to a backhole (peer no more reachable) while having many messages to send (Full send-Q).

Later we can refactor syscall.SendmsgN(c.fd(), b, cbuf, nil, syscall.MSG_DONTWAIT) to a better one.

[gomaja]

Rebased and restructured this to make it reviewable.

The branch had grown to seven commits covering four unrelated things. It is now two: the close fix, and its tests.

The MSG_DONTWAIT change moved out to #90 — it changes SCTPWrite's contract for every caller and should not ride along in a close-logic PR.

While adding tests I found the descriptor guard bug: fd > 0 skips fd 0, which is a valid descriptor, so a connection landing there leaked. Fixed here, with a test that fails if the guard is put back. Also handled the discarded syscall errors in closeSctpSocket and exposed the grace period through CloseWithTimeout instead of hardcoding it.

The original seven commits are preserved at backup/pr87-original on my fork if any of the intermediate history is wanted.