SIGHUP reload can falsely report 'network config change' after a TLS downgrade

[coderdan]

Context

Surfaced in review of PR #397. On startup, init may downgrade the in-memory TandemConfig when inbound TLS is misconfigured and TLS isn't forced: it sets config.tls = None and config.server.require_tls = false, then falls back to a plaintext listener (packages/cipherstash-proxy/src/main.rs).

On SIGHUP, reload_application_config loads a fresh TandemConfig from env/file and compares it against the running (downgraded) config via has_network_config_changed, which checks config.tls and config.server.require_tls. Because the freshly loaded config still shows TLS configured while the running config was downgraded, the comparison sees a difference and returns NetworkConfigurationChangeRequiresRestart — refusing an otherwise-valid reload.

Impact

Low/corner-case: only when (a) inbound TLS was present but invalid at startup, (b) TLS was not forced (so it downgraded), and (c) a SIGHUP reload is attempted. The current behaviour is conservative — it refuses the reload rather than crashing or silently changing the listener's security posture — but it's surprising.

Proposed fix

Normalize both configs to the same effective/network representation before comparing — e.g. extract the startup TLS-downgrade logic into a helper and apply it to the freshly loaded config inside reload_application_config before has_network_config_changed, or have has_network_config_changed compare effective TLS state rather than raw tls / require_tls.

Acceptance criteria

• After a startup TLS downgrade, a SIGHUP reload that does not actually change network config succeeds instead of reporting a spurious change.
• A genuine network/TLS config change still correctly requires a restart.