docker: switch base image from distroless/base to distroless/static:n…

…onroot (#224)

This cuts image size in half and improves security posture by
default, at the cost of a bit more complexity for what should
be slightly unusual deployments (privileged ports AND host
network).

---------

Signed-off-by: Kohei YOSHIDA <kohei@yosida95.com>
Co-authored-by: Will McCutchen <will@mccutch.org>

ci: fix OCI image annotations (#217)

fix: actually test fix for local port number in `/ip` response (#213)

fix: /response-headers does not need escaping by default (#208)

The fix in commit 0decfd1 for a potential XSS vulnerability[1] in the
`/response-headers` endpoint made an unintentionally breaking change, by
HTML-escaping the body of the response when no explicit `Content-Type` is
specified in the incoming request.

We do not need to escape by default, because we default to a safe JSON content
type in that case.

[1]: GHSA-528q-4pgm-wvg2

Merge commit from fork

* fix: prevent reflected XSS in `/response-headers` endpoint

* link to security policy from README

* decompose/refactor a bit

* apply same fix to /base64 endpoint

* fmt

* switch to allowlist of safe content types, w/ config option for backwards compat

* readme styling

ci: push to ghcr.io (again) (#201)

ci: push to ghcr.io in addition to docker hub (#200)

Motivated by Docker's much more aggressive [rate limits][1] on
unauthenticated pulls of public images going into effect on April 1:

[1]: https://docs.docker.com/docker-hub/usage/

feat: allow specifying content-type for `/base64` responses (#198)

Given that the `/base64/{data}` (and `/base64/decode/{data}`) endpoint
allows decoding arbitrary data, I think it makes sense to allow the
client to also specify the `Content-Type` of that data while maintaining
`text/plain` as the safe default.

See conversation starting here[1]
for context and motivation for this change.

[1] #141 (comment)

feat: add /env endpoint to allow exposing operator-controlled info fr…

…om the server (#189)

Fixes #114

feat: add `Server-Timing` headers/trailers where relevant (#186)

Here we add [Server-Timing
headers/trailers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server-Timing)
to endpoints that let clients control response timing:

- `/delay` (header)
- `/drip` (header)
- `/sse` (trailer)