connector, mux: close four network-management gaps

[canaan5]

Found while tracing ISW/ZONE link instability in a downstream acquirer. Each gap forced a workaround that could not fully fix the problem from outside the library. All four changes are additive — an existing configuration behaves exactly as before.

1. No way to reply to an unsolicited frame

Unsolicited handed over the frame and nothing else, and neither Mux nor Connector exposed a raw Send, so a peer-initiated message could not be answered at all. Request is the wrong tool — the frame we would send is the response, so there is nothing to wait for.

This matters because Postilion-family hosts do not only answer echoes, they send them: a host that echo-tests us and never receives an 0810 concludes the link is dead and closes it, which is indistinguishable from a flapping network.

Adds mux.Reply, mux.WithUnsolicitedReplier, (*Mux).Send, (*Connector).Send, connector.Config.OnUnsolicited.

2. Keyer is direction-blind

One keyer served both directions. With a single function no keyer can match a response to its request and separate a peer's request from our own — the two are structurally identical. Network management correlates on the trace alone (an echo carries no terminal id), so a peer 0800 on a colliding trace was delivered as our 0810 while the real answer arrived unmatched and was dropped.

Adds mux.WithResponseKeyer / connector.Config.ResponseKeyer: the request keyer maps an outgoing frame to the key of the response it expects, the response keyer maps an inbound frame by its own MTI. Our 0800 registers under 0810:<trace>, the real 0810 matches, and a peer's 0800 keys to 0800:<trace> — no match, so it reaches the unsolicited handler where it belongs.

3. A keepalive inherited the request timeout

Worth stating precisely, because the obvious diagnosis is wrong: a peer that dies cleanly (EOF/RST) fails the mux from the read loop, which unblocks the pending keepalive immediately — the synchronous serve loop handled that case fine.

The gap is the half-open peer — TCP established, application silent, no FIN (a NAT idle-out, a wedged host thread). Nothing closes the mux, so the echo waits out Timeout, a value sized for a financial round-trip. Until it gives up the connector goes on reporting Connected() and accepting requests onto a socket that will never answer: a window of KeepaliveInterval + Timeout.

Adds connector.Config.KeepaliveTimeout, bounding one keepalive independently (0 falls back to Timeout). serve also runs the keepalive off the supervise loop — that does not shrink the half-open window, but it stops an outstanding keepalive holding Stop hostage.

4. No hook after the mux is published

OnConnect runs before c.mux.Store(m). That ordering is right for sign-on — the session must exist before the link is usable — but it leaves nowhere for a ceremony that must go through the connector's own request path (a working-key exchange, a parameter download): from OnConnect it fails ErrNotConnected.

Adds connector.Config.OnReady, invoked in its own goroutine right after the mux is published. Unlike OnConnect it cannot drop the link — its failure is the caller's to handle.

Tests

Six, in connector/netmgmt_test.go, over a small line-framed peer:

• a peer-originated echo is answered, and the answer reaches the peer
• Send on a down link returns ErrNotConnected
• with ResponseKeyer, a peer request on our trace reaches the unsolicited handler and our own request still times out
• a half-open peer is detected without waiting out the request timeout — this one fails without KeepaliveTimeout
• an outstanding keepalive does not block Stop
• OnReady can use the connector; OnConnect cannot (documents why OnReady exists)

go vet, gofmt and the full suite are clean.