fix: share one HTTP client per provider and size its connection pool

[alexluong]

Closes #1017.

Outpost built a separate http.Client for every destination and never configured pooling on it, so each inherited Go's default of two idle connections. Above two concurrent deliveries to a destination, reuse collapsed to roughly one new connection per delivery.

What changed

One client per provider. Nothing in the client configuration varies per destination — user agent, proxy settings and the transport wrapper all come from provider-level options fixed at registration — so the client moves from CreatePublisher to the provider constructor (destwebhook, destwebhookstandard, desthookdeck). This also means publisher-cache eviction no longer throws away the connection pool.

The rule the code now documents: only connection-level concerns justify a separate client. If per-destination proxy or client certificates are needed later, transports should be keyed by configuration and shared within a key.

Derived pool sizing (internal/destregistry/connpool.go):

	source	floor / cap
per-host (depth)	DELIVERY_MAX_CONCURRENCY	floored at 2 (Go's default)
total (breadth)	RLIMIT_NOFILE / 4	floored at 100, capped at 4096

Breadth doesn't derive from concurrency — a deployment with 600 destinations each receiving one delivery a minute has almost no concurrency but needs ~600 warm connections. The hookdeck provider talks to one host, so it gets a depth-only pool.

No new configuration. The correct total depends on the active destination count and the host's FD limit, which an operator would need to know both of to set sensibly. Instead:

• resolved values logged at startup (delivery_max_idle_conns, delivery_max_idle_conns_per_host, delivery_conn_pool_fd_limit)
• new outpost.delivery_connections counter, dimensioned by type and reused — the signal that the ceiling is binding

Adding a knob later is backward-compatible; removing one isn't.

Platform. RLIMIT_NOFILE is read behind a unix build tag; Windows falls back to an assumed 1024.

Tests

internal/destregistry/httpclient_pool_test.go counts TCP connections opened at an httptest server via ConnState, swept across concurrency levels against both fast and slow destinations — the two regimes fail differently (latency vs. ephemeral ports). Connections opened track the concurrency level, not the request count.

A control case runs the identical workload through a stock-default client so the assertion can't pass trivially: at concurrency 32, stock opens ~120 connections for 320 requests, sized opens 32.

destwebhook_connpool_test.go covers the provider half — 8 publishers, 40 requests, still bounded by concurrency.

Behavior changes worth flagging

• An invalid DESTINATIONS_WEBHOOK_PROXY_URL now fails at startup instead of on first publish.
• Idle connections are held on the receiver for up to 90 seconds after a delivery. Those connections were opened anyway; pooling changes whether they're held afterward.
• The pool is shared across tenants. Connections are per-host so there's no correctness concern, but a busy tenant can evict a quiet tenant's idle connections; the per-host limit bounds the blast radius.

Verification

go test -short ./... clean. Pool tests run at -count=15 for flake.

🤖 Generated with Claude Code

[alexluong]

Added #1022 in d4d1175 — pulled back out. #1025 rewrites the same signature formatter constructors this touched, so keeping the two together meant one PR blocking the other on a merge conflict for no reason. #1022 will land separately, based on #1025.

This PR is #1017 only: connection pooling.