Let clients request gzipped responses from the external API

[david-crespo]

Will update with examples of how much smaller the responses are and more detail about what I've tested locally and how we should test this on real systems. In my most recent testing we get about 80% compression on bigger responses. JSON is extremely repetitive.

Changes

Flip CompressionConfig::None → CompressionConfig::Gzip on dropshot_external in sled-agent/src/services.rs. Internal and lockstep are left as-is for now. oxidecomputer/dropshot#1448 in dropshot 0.17 does all the real work:

• streaming gzip via async-compression
• content-type allowlist (application/json, text/*, application/xml, ndjson, +json/+xml)
• exclusions for HEAD, 1xx (so the serial-console websocket upgrade is safe), 204, 304, 206, Content-Range, already-encoded responses, text/event-stream, and bodies under 512 bytes
• RFC-compliant Accept-Encoding + q-value parsing
• opt-out via a NoCompression extension marker
• Vary: Accept-Encoding on every compressible response whether or not it was actually compressed

The console asset logic in nexus/src/external_api/console_api.rs already serves precompressed .gz files with Content-Encoding: gzip set, and dropshot's should_compress_response skips anything with that header, which avoids double-encoding.

[david-crespo]

It seems this is the one that matters for production.

[david-crespo]

I think this turns it on for all tests. Not sure we want to do that, but for the most part it doesn't matter because I don't think requests in tests ask for gzipped responses by default.