fix(dns): back off on TCP accept errors instead of spinning

[adrgs]

Summary

A DNS-over-TCP accept() failure caused an unbounded hot loop that took production down to a crawl. This adds a 100ms backoff on accept errors.

Root cause

When the process exhausts its file descriptors, accept() returns EMFILE and leaves the pending connection queued. The error arm logged and looped straight back into accept(), which failed on the same connection immediately:

Err(e) => {
    error!("Error accepting DNS TCP connection: {}", e);
}   // <- back to accept(), same connection, same error

The spin then starved the very tasks that would have closed descriptors, so the process could not recover on its own.

Production impact

Observed on a 1 OCPU host with the container's soft RLIMIT_NOFILE at the 1024 default (1018 of those FDs were sockets):

Metric	During incident	After raising the FD limit
Error log rate	~1,600 lines/sec	0
Container CPU	149%	1.05%
CPU steal	65-72%	negligible
TLS handshake	12-18s, ~1 in 5 timing out	~90ms

Because TLS handshakes are the most CPU-hungry part of the request path, they degraded first and worst. Plain HTTP returned Empty reply from server and sshd could not be scheduled reliably — the box looked network-broken when it was purely CPU-starved.

The fix

Back off 100ms after any accept error, not just resource exhaustion. Checking for EMFILE/ENFILE specifically would need a libc dependency for two constants, and a brief pause is the right response to any unexpected accept failure. The existing semaphore-exhaustion path already drops stream correctly and is unchanged.

Note on the first commit

394fbab applies cargo clippy --fix for uninlined_format_args across certs/dns/http/tcp. Those fire on current stable clippy on a clean main and blocked the pre-commit hook, so they had to be resolved to commit at all. Kept as a separate commit so the actual fix stays reviewable.

Testing

• cargo test — 84 passed, 0 failed (1 ignored: ACME staging, needs a real domain)
• cargo clippy --all-targets -- -D warnings — clean
• cargo fmt --check — clean

Follow-up worth considering (not in this PR)

• Raise the container's nofile limit in docker-compose.yml; the 1024 default is low for a process with four listeners. Already applied to the running production host.
• Rate-limit that error log. 100k lines/minute is its own denial of service, and with max-size: 10m rotation it destroys the diagnostics you need.
• Investigate why FDs reached 1024 — this PR stops the spin, but the exhaustion itself is a separate question.

🤖 Generated with Claude Code