Add HTTP response processing mode with lazy decompression

[vlsi]

What

Replaces the boolean "Save response as MD5 hash?" option on HTTP Request and HTTP Request Defaults with a Processing mode combo that controls how the response body is handled:

• Default — leave the property unset: inherit from HTTP Request Defaults if set, otherwise behave like Store response.
• Store response (decompress on access) — store the raw, possibly compressed, body and decompress it lazily, only when it is read (assertion, post-processor, listener). The new default; responses that are never read are never decompressed, saving CPU and memory.
• Fetch and discard (headers only) — read the response but do not store the body.
• Checksum (MD5 of compressed) / Checksum (MD5 of decompressed) — store a 32-character MD5 hash instead of the body. The decompressed variant matches the former "Save as MD5".

It also adds a ResponseDecoder SPI with gzip, deflate, and brotli decoders (so decompression runs lazily and is pluggable) and a tooltip explaining the field.

Builds on #6389 by @jgaalen (discussion in #6388); the first commit keeps him as author.

Why the migration is resolve-on-read

The legacy behaviour is driven by the boolean HTTPSampler.md5, which can live in two places: on the sampler (HTTPSamplerBase) and on HTTP Request Defaults (a ConfigTestElement). Old plans must keep working, and an explicit md5=false on a sampler must still override md5=true inherited from the defaults.

A migration that rewrites md5 → responseProcessingMode in setProperty cannot close both cases:

• ConfigTestElement lives in core, which cannot reference the HTTP enum/schema (the dependency is http → core), so the defaults element can't be migrated there.
• A setProperty migration only sees an element's own properties; the md5 inherited from the defaults reaches the sampler through config merge (mergeIn / addProperty), which bypasses setProperty.

So correctness is resolved on read: getResponseProcessingMode() returns the explicit responseProcessingMode when set, otherwise falls back to the legacy md5 — the sampler's own, or the one inherited from the defaults via merge — otherwise the schema default. This reuses the existing boolean merge semantics (an explicit md5=false overrides an inherited md5=true), so both the sampler and the HTTP Request Defaults cases behave exactly as before, for any origin: loaded JMX, plans built programmatically, or direct property access. The GUI additionally rewrites the property to responseProcessingMode and drops md5 when the element is saved.

TestElementUpgrader SPI — will be split into a separate PR

The second commit adds a small core SPI — TestElementUpgrader, discovered via ServiceLoader and run by SaveService right after a plan is loaded — that upgrades legacy property values on load (NameUpdater only renames keys/classes). The HTTP-side ResponseProcessingModeUpgrader rewrites md5 → responseProcessingMode; because it keys off the property name, it upgrades both samplers and the ConfigTestElement defaults, without core depending on http.

It is not required for correctness (resolve-on-read already covers runtime); it just normalises old plans into the new property on load and re-save. I will extract it into its own PR — it is included here only to show the full picture and a concrete usage example. Happy to drop that commit from this PR if you prefer.

How to verify

• ./gradlew :src:core:testClasses :src:protocol:http:testClasses
• New tests: ResponseProcessingModeInheritanceTest (resolve-on-read, inheritance and override), HttpTestSampleGuiResponseProcessingModeTest / HttpDefaultsGuiResponseProcessingModeTest (GUI round-trip), ResponseProcessingModeUpgraderTest / ResponseProcessingModeUpgradeOnLoadTest (the SPI), plus the ported ResponseDecoderRegistryTest and gzip/deflate/brotli decoder tests.
• In the GUI: HTTP Request → Advanced → Response Processing. Load a plan that used "Save response as MD5 hash?" and confirm the combo shows Checksum (MD5 of decompressed).

🤖 Generated with Claude Code