Skip the compressor for clients that offer no encoding

Listing latency at one user went from 1.95 ms on the previous release to
3.25 ms on main, and a bisect put the whole of it on the compression commit.
Not on compressing: the harness never sent Accept-Encoding, so nothing was
ever gzipped. Hono's middleware still inspects every compressible response it
declines and sets Vary on it, and setting a header on a streamed passthrough
rebuilds the Response off its fast path -- about 1.2 ms per JMAP call, on a
request that had asked for nothing.

The middleware now runs only when the request names gzip or deflate. Measured
at one user against the same Stalwart:

  compressor touches but declines, no Accept-Encoding   3.25 ms
  skipped entirely, no Accept-Encoding                  2.02 ms
  compressor applied, Accept-Encoding: gzip             2.27 ms
  previous release, either                              1.95 ms

Applying gzip to a JMAP response costs about a quarter of a millisecond and
saves three to five times the bytes on every listing and body, so JMAP
responses stay compressed by default; COMPRESS_JMAP=0 turns that off for a
deployment that would rather not.

The raw push relay is also made safe to tear down from outside -- the
browser stream keeps its headers and is not ended when the upstream request
goes -- which the next change relies on.

server/src/compress.test.ts

@@ -98,3 +98,10 @@ test("the data path is rate limited per session, and login stays on its own budg
   assert.ok(l.retryAfterSeconds("s1") >= 1);
   assert.equal(l.check("s2"), true, "another session is not affected");
 });
+
+test("a response to a client that offered no encoding is not touched by the compressor", async () => {
+  const res = await createApp().request("/assets/app.js");   // no Accept-Encoding at all
+  assert.equal(res.status, 200);
+  assert.equal(res.headers.get("content-encoding"), null);
+  assert.equal(res.headers.get("vary"), null, "no Vary: the middleware never ran");
+});