http::server: no compression, and it is the first thing here that needs a dependency

[xoloki]

Content-Encoding and Accept-Encoding are unimplemented. The server now
serves text files -- HTML, CSS, JavaScript, JSON -- which is exactly the
content compression is for.

Why it is not simply "call deflate"

Two things just built make the wrong assumptions if compression is bolted on:

• Content-Length stops being st_size. files() gets the length from
  stat before reading a byte, which is what lets it send a counted body and
  seek for a range (net: files stream a block at a time, counted rather than chunked -- and the break harness that called a crash a pass #226, net: byte ranges for any body, not only files -- and four guards that could not be broken until they changed #227). A compressed body's length is not known until
  it has been compressed, so a compressed file is either buffered whole --
  giving back what net: files stream a block at a time, counted rather than chunked -- and the break harness that called a crash a pass #226 bought -- or chunked, giving back the counted framing.
• A range of a compressed body is not a range of the file. RFC 9110 is
  clear that Range applies to the selected representation, so once
  Content-Encoding: gzip is on, bytes=0-99 means the first hundred octets
  of the gzip stream, not of the file. Getting that wrong means a client
  seeking in a video receives nonsense.

That interaction is the work. The compressing is a library call.

And it needs zlib

configure.ac does not look for it. It would be an optional module gated by
AM_CONDITIONAL, like libsodium, PortAudio and ImageMagick++ -- so the server
would have to work with and without, and the tests would have to cover both.

Not in this

• No Brotli or zstd. Accept-Encoding negotiation should be written so adding
  one is a table entry, but only gzip and identity would exist.
• No compressing a response a handler already produced compressed.