feat(booster-http): --compression-level flag for piece & frisbii, fix GzipHandler usage

[rvagg]

This is a stacked PR on top of #1676; one of a couple I'm going to do to consolidate and address some things with the two primary HTTP handler paths.

This one does a few things:

• New --compression-level flag with a default of 1. Allows users to turn it off if they're going to do this in a reverse proxy (recommended, really).
• Plumb through the same level to Frisbii as well as the piece handler
• Replace the direct usage of gziphandler.GzipResponseWriter in the piece HandlerFunc with a gziphandler.MustNewGzipLevelHandler() as a Handler, wrapping the HandlerFunc - this does two things: (1) lets us set a compression level, the default we're getting now is a basic deflate (1), and (2) lets us use the gzip pool that gziphandler manages at the level of Handler.
• Add a couple of extra headers for the piece handler, including a Cache-Control.
• A bunch of tests to make sure it's working - the existing test just sets a header and adds a gzip reader, which is already done internally (transparently) by the Go HTTP client; so the tests added here to a variety of on and off for compression.

I've set the default to 1 but I'd rather set it to 6 for better results, with a small amount of CPU impact. I chose 1 because that's all users are getting now.

[rvagg]

test failing because of a minor compatibility problem with [email protected], going to cut a new version soon with some other updates for my next PR so I'll roll that in here and the test will turn green

[rvagg]

released [email protected], updated to that in #1676 and that should address the CI problems here

[masih]

I will review the final PR against main more closely. Based on a quick look this looks fine 👍

[rvagg]

I've pulled this in to #1676, it car be reviewed there as part of the mega-changeset but is still a separate commit that can be viewed separately if desired.