fix(ship): resolve double connections by SKI and recency (TC_SHIP_CONN_001)

[kirollosnct]

fix(ship): resolve double connections by SKI and recency (TC_SHIP_CONN_001)

Fixes #96.

The problem

SHIP 12.2.2 says the node with the bigger 160-bit SKI keeps the most recent
connection to a peer and closes all others. keepThisConnection implemented something
else — keep whichever connection the higher-SKI node initiated — and said so in its own
comment:

// This is hard to implement without any flaws. Therefore I chose a
// different approach: The connection initiated by the higher SKI will be kept

That rule is symmetric, so it always converged on one connection, but it is not the
spec's rule, and TC_SHIP_CONN_001 fails on it. With the DUT holding the larger SKI the
test tool opens connection B as soon as it sees the TCP stream of the DUT's connection A;
the DUT is required to keep B and close A, and instead keeps A and tears down B after B
has completed a handshake.

Getting the criterion right is necessary but not sufficient. The old check ran after the
TLS handshake and the websocket upgrade, while the test expects A closed "within 30s
(latest before the TLS handshake of connection B completes)" — and at that point A is not
even a connection yet, it is an in-flight dialer.Dial with no handle to cancel.

What changed

The criterion. keepThisConnection is replaced by resolveDoubleConnection. The
direction a connection was opened in is no longer an input — that parameter was the bug.

The decision moved into the TLS handshake. verifyPeerCertificate now performs the
arbiter check, which is what SHIP 12.2.2 asks for: "The SHIP node with the greater SKI
SHOULD check for double connections directly during the TLS handshake." It never rejects
the incoming connection; it only retires the older one.

The outgoing dial became cancellable. connectionsInitiating carries the raw socket
(dialState), so that check can abort an in-flight dial synchronously instead of waiting
for it to return. This is the case TC_SHIP_CONN_001 actually produces, and the one that
has to beat the handshake deadline.

The registry owns the swap. registerConnection installs the new connection and
retires what it displaced in one step, so the map never passes through a state where the
SKI has no connection. A displaced connection can therefore tell it was replaced rather
than disconnected.

Two smaller spec items. A superseded connection that had reached data exchange is now
closed with the SHIP 13.4.7 termination announce rather than a socket close, and the
double close that raced its own close frame is gone — a rejected connection reports
4001 "double connection" instead of dying at 1006 "unexpected EOF".

A retired dial no longer reports success unconditionally. It is retired during the
incoming connection's TLS handshake, before that connection has shown it can get past
ServeHTTP at all. If it never establishes, the SKI would be left with nothing connected
and nothing scheduled to fix it, so the dial now waits briefly and then reports a failure
onto the existing retry path.

The first commit (fix(ws)) is a prerequisite: every websocket write now sets its own
deadline. A deadline stays armed on the socket after the write it was set for, and only a
SHIP message or the 50 s keepalive refreshed it, so an established connection idle for
more than writeWait failed its next write instantly — and gorilla latches write errors.
The write most exposed to that is the close frame, which is exactly the 4001 this PR
relies on.

Testing

New scenarios drive a real Hub over real TLS sockets against a scripted SHIP peer, so
the behaviour is observed the way the certification tool observes it — which socket died,
with which close code, and in which order relative to the TLS handshake:

Test	Covers
TestDoubleConn_TC_SHIP_CONN_001_IncomingDuringInflightDial	the ordering the test spec describes: B arrives while A is still an in-flight dial
TestDoubleConn_TC_SHIP_CONN_001_IncomingAfterEstablished	A already registered when B arrives (the 30 s bound)
TestDoubleConn_TC_SHIP_CONN_001_ClosesBeforeHandshakeCompletes	A closed before B's TLS handshake completes
TestDoubleConn_ReplacementDoesNotReportDisconnect	no disconnect callback when a connection is replaced
TestDoubleConn_SupersededConnectionInDataExchangeIsAnnounced	SHIP 13.4.7 announce, reason unspecific per 13.4.7.1.1
TestDoubleConn_SupersededDialFailsIfIncomingNeverEstablishes	a retired dial that leads nowhere is retried
TestDoubleConn_TLS13PeerResolvesLateButCorrectly	documents the TLS 1.3 split above
TestDoubleConn_DistinctPeersBothSurvive	TC_SHIP_ROLE_003 guard: two distinct SKIs must both survive
TestWriteOnIdleConnection, TestCloseFrameOnIdleConnection	the write-deadline fix

Each new test was verified to fail without its fix. Existing tests that encoded the old
criterion were rewritten rather than deleted — Test_KeepThisConnection_DirectTest →
Test_DoubleConnectionResolution_DirectTest, TestKeepThisConnectionBasics →
TestDoubleConnectionActionBasics, plus TestDoubleConnectionPreventionEdgeCases,
connection_race_fix_test.go and connection_delay_safety_test.go.

🤖 Generated with Claude Code

[coveralls]

coverage: 93.086% (+0.3%) from 92.773% — fix/ship-double-connection into dev