sm: implement post-CER/CEA TLS upgrade (RFC 6733 §6.2)

[tridentsx]

Add support for upgrading a plain TCP connection to TLS after the CER/CEA exchange, as specified in RFC 6733 §6.2.

Changes

• Add TLSUpgrader interface to diam package
• Add StartTLS(*tls.Config) error method to the server connection
• Add TLSConfig *tls.Config field to sm.Settings
• Update handleCER: when peer sends Inband-Security-Id=1 and server has TLSConfig, accept the CER, send success CEA, then upgrade to TLS
• Add ParseWithSecurity() and RequestedSecurity() to CER parser
• Add test verifying server accepts Inband-Security-Id=1 when TLSConfig is set

RFC Reference

RFC 6733 §6.2:

If TLS is to be used with a Diameter connection, the TLS handshake MUST begin immediately following the CER/CEA exchange for connections that are not pre-configured to use TLS.

Backwards Compatibility

Without TLSConfig set in Settings, existing behavior is preserved (Inband-Security-Id=1 is rejected with NO_COMMON_SECURITY on plain connections).

All existing tests pass. The SCTP close test failure is pre-existing on upstream main.

Fixes #238
Related: #236, #239

[fiorix]

Useful direction but a few things to resolve before merging:

1. Server-only upgrade. StartTLS lands on *response but there's no client-side counterpart. Without one, no in-tree peer can complete the upgrade — which is why the new test acknowledges it can't actually drive the handshake. RFC 6733 §6.2 requires both sides to upgrade.

2. Concurrency. StartTLS swaps w.conn.rwc, w.conn.sr.r, and w.conn.buf. The serve loop reads via w.conn.buf without holding w.mu. As long as the upgrade happens inside handleCER before the loop reads the next message it's probably safe in practice, but the invariant should be documented and asserted (e.g. only callable from a handler, before the next read).

3. Failed upgrade after success CEA. On StartTLS error the conn is closed, but the peer already received a success CEA. Either send a failure CEA on upgrade error, or document that an immediate close after success CEA means upgrade failure. (Doing the upgrade before the CEA contradicts §6.2.)

4. Silent downgrade for non-upgradeable conns. canTLS := tlsActive || sm.cfg.TLSConfig != nil accepts Inband-Security-Id=1 even when c.(diam.TLSUpgrader) fails the type assertion (e.g. SCTP, third-party transports). The upgrade is silently skipped and the conn stays plaintext after success CEA. Should reject the CER in that case.

Suggestion: split into (a) TLSUpgrader interface + server-side StartTLS as infra (this PR, scoped down), (b) client-side StartTLS, (c) handleCER orchestration with the safeguards above. Or hold this PR until (b) lands so we can ship them together with an end-to-end test.

#240, #241, #242 can land independently of this — they're useful on their own and don't block the design discussion here.

[fiorix]

Thanks — the new commit addresses three of the four concerns nicely:

• ✅ Client side: StartTLSClient + Client.RequestInbandTLS + handleCEA upgrade closes the loop. Both peers can now complete the handshake.
• ✅ Concurrency invariant: documented on the interface ("must be called from within a handler before the next read"). Good.
• ✅ No more silent downgrade: canTLS now requires c.(diam.TLSUpgrader) to succeed, and the upgrade path also rejects defensively.

Two things left:

1. Dictionary for Credit-Control Applications #3 from the original review still open: on StartTLS failure the conn is closed after a success CEA was sent — peer sees success-then-RST. Consider sending a failure CEA instead, or at minimum document that an immediate close after success CEA means upgrade failure.

2. Rebase against main: this PR is currently mergeable=dirty (sm: accept Inband-Security-Id=1 when TLS is already established #242 landed and conflicts with the parser changes here). Once rebased, CI will rerun and we can validate end-to-end with the new client-side path.

Also worth adding now that both sides are wired up: an integration test that drives a full plain→CER/CEA→TLS handshake using the new StartTLSClient. That would have been impossible before this revision and is the strongest proof the feature works.

[tridentsx]

I tried to address those last things please check if taths ok !