Compress /api/v1 responses with gzip

[LarsLaskowski]

📖 Description

GET /api/v1/metrics/history returns highly repetitive JSON (a fixed set of
time series, each point ~50 bytes) that can reach several hundred KB per poll
on a Pi with multiple disks/interfaces at the default 60-minute/5-second
history window. writeJSON never compressed responses, so this payload was
re-sent in full, uncompressed, on every poll — noticeable on a Pi Zero over
Wi-Fi both in transfer time and CPU.

This adds a withGzip middleware (internal/httpapi/middleware.go) using
only the standard library:

• If the request's Accept-Encoding doesn't contain gzip, the request
  passes through unchanged (identity response, unmodified for existing
  clients).
• Otherwise it sets Content-Encoding: gzip and Vary: Accept-Encoding,
  drops any Content-Length, and wraps the ResponseWriter so Write goes
  through a pooled *gzip.Writer at gzip.BestSpeed (a sync.Pool avoids
  per-request writer allocation; WriteHeader is forwarded automatically via
  the embedded http.ResponseWriter).

withGzip wraps the four /api/v1/... routes in server.go
(/api/v1/metrics, /api/v1/metrics/history, /api/v1/alerts,
/api/v1/config). /healthz is left uncompressed (2-byte body, not worth
it).

🎫 Issues

Closes #23

👩‍💻 Reviewer Notes

Smoke-tested locally:

$ curl -s -o /dev/null -w '%{size_download}\n' http://localhost:8080/api/v1/metrics/history
907
$ curl -sH 'Accept-Encoding: gzip' -o /dev/null -w '%{size_download}\n' http://localhost:8080/api/v1/metrics/history
279

(compression ratio grows with history size — the fixture above only had a
handful of history points; a full 60-minute window compresses closer to the
~10x mentioned in the issue, since it's far more repetitive.)

📑 Test Plan

• New test TestHandleHistory_GzipWhenAccepted in middleware_test.go:
  builds a 500-point history fixture, requests it both without and with
  Accept-Encoding: gzip, and asserts the gzip response carries
  Content-Encoding: gzip / Vary: Accept-Encoding, is smaller than the
  identity response, and gunzips to byte-equivalent JSON.
• go build ./..., go vet ./..., go test ./... -race -cover, and
  golangci-lint run all pass locally.

✅ Checklist

General

• I have added/updated tests for my changes (go test ./... -race -cover passes locally).
• go vet ./... and golangci-lint run are clean.
• I have tested my changes.
• I have read the CONTRIBUTING documentation and followed the project's code style guidelines.
• I have updated ARCHITECTURE.md if this changes a documented design decision. (not applicable — this is an internal HTTP-layer optimization, not a documented architectural decision)

REST API / configuration / packaging

• I have updated docs/API.md to reflect a REST API change. (new "Compression" section)
• No breaking change to /api/v1/... response shapes, or a new API version (/api/v2/...) was introduced instead. (response bodies are byte-identical after decompression — only the wire encoding changes, and only for clients that opt in via Accept-Encoding: gzip)

⏭ Next Steps

None.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud