l4postgres: add Postgres STARTTLS (terminate inbound + re-originate outbound)

[tannevaled]

What

Adds PostgreSQL STARTTLS support to l4postgres, in both directions:

• Inbound — postgres_starttls handler: reads the 8-byte SSLRequest, replies S, and hands off. Put a tls handler next to terminate TLS; the handlers/matchers that follow then see the cleartext startup message (user, database, application_name). It reuses the existing tls handler (no TLS code duplicated).
• Outbound — StartTLSClient(conn, *tls.Config): re-originates TLS to a Postgres upstream that expects sslmode != disable (sends SSLRequest, expects S, performs a tls.Client handshake).

Why

PostgreSQL doesn't begin TLS with a ClientHello — a libpq client sends SSLRequest and waits for S/N before the handshake (see #187). So the generic tls handler can't terminate a classic Postgres connection on its own. (PostgreSQL 17+ can negotiate TLS directly via ALPN postgresql, which the existing tls matcher/handler already covers — see docs/examples/postgres-over-tls.md; this handler is for the classic SSLRequest flow.)

Working example (verified by a caddyfile_adapt integration test in this PR):

{
    layer4 {
        :5432 {
            @pg postgres
            route @pg {
                postgres_starttls
                tls
                proxy upstream.local:5432
            }
        }
    }
}

Once cleartext, this composes with content matchers such as those proposed in #188 — e.g. adding a postgres { database acme } matcher (from that PR) inside the route after tls to route by database. (#188 isn't merged, so it's intentionally left out of the example above.)

Notes / design

• The outbound part is a self-contained function rather than wired into l4proxy, to avoid coupling the generic proxy to Postgres. It would slot in behind an opt-in upstream STARTTLS hook — happy to shape that in review, or split the outbound piece into its own PR. Terminate-only deployments (backend on a trusted/encrypted network) don't need the outbound side.

Tests / docs

• starttls_test.go: inbound (replies S / rejects non-SSLRequest / read & write error branches), outbound (real TLS handshake against a self-signed test server / N refusal / write, reply-read, unexpected-reply, and handshake error branches), and Caddyfile parsing. 100% statement coverage of the new code.
• integration/caddyfile_adapt/gd_handler_postgres_starttls.caddytest: verifies the example above adapts to the expected JSON.
• docs/handlers/postgres_starttls.md.
• go test ./... -race, gofmt, go vet, golangci-lint clean; no go.mod change.

Builds on #187 and complements #188.

[vnxme]

Thank you for your latest contributions! Please add integration tests and documentation. The Postgres-over-TLS example may also require updating.

The config example in the why section above seems a bit strange - could you please explain why you need two postgres handlers? Neither do they exist, nor are they introduced by the PR -- or am I missing anything? Have you tested this code/example yourself?

[tannevaled]

You're right, and thanks for the careful read — the example in the description was wrong as written: it mixed the postgres matcher with handlers and used a postgres { database ... } matcher form from #188 that isn't merged. I'd sketched it to illustrate the end state rather than adapting it, which is exactly the wrong shortcut. Apologies.

I've fixed it and added what you asked for:

• A correct, L4 module for Postgres: matchers #188-independent example (matcher in @pg postgres, handlers postgres_starttls → tls → proxy in the route), now verified by a caddyfile_adapt integration test (gd_handler_postgres_starttls.caddytest) — so it's checked to adapt, not asserted by hand.
• Documentation: docs/handlers/postgres_starttls.md.
• Test coverage of the new code brought to 100% (inbound + outbound, including the error branches).

On docs/examples/postgres-over-tls.md: it covers the PostgreSQL 17+ direct-TLS (ALPN postgresql) path, which is a different mechanism from the classic SSLRequest flow this handler targets, so I left it as-is and cross-referenced it from the new handler doc instead. Happy to add a short STARTTLS note there too if you'd prefer.

The PR description is updated accordingly. Thanks again — and please tell me if you'd rather I split the outbound StartTLSClient piece into its own PR.