Add configurable compression

[Long9725]

Make compression pluggable and configurable (gzip level/buffer), retain API compatibility

Overview

• Introduces configurable gzip compression (level, buffer size) and a pluggable output filter factory for HTTP/1.1. Preserves the original API to maintain backward compatibility.

Changes

• CompressionConfig: add gzipLevel and gzipBufferSize with validation; add configurable noCompressionEncodings; extend useCompression to accept an encoding; restore the original useCompression(Request, Response) overload
  delegating to gzip.
• AbstractHttp11Protocol: expose getters/setters for gzip settings; add OutputFilterFactory support (by instance and by class name with error handling); delegate compression checks using the factory’s encoding; expose get/
  setNoCompressionEncodings.
• http11.filters: add OutputFilterFactory interface and default GzipOutputFilterFactory; update GzipOutputFilter to honor level and buffer size.
• Http11Processor/HTTP2 StreamProcessor: construct gzip filter using protocol-provided level/buffer settings.
• Tests: update existing tests and add coverage for gzip level/buffer, output filter factory, and no-compression encodings.
• Docs/I18N: document gzipLevel, gzipBufferSize and noCompressionEncodings in webapps/docs/config/http.xml; add related LocalStrings messages.

Influence

• Compatibility: no breaking changes; existing behavior remains default (gzip enabled per prior rules, default level -1, buffer 512).
• Extensibility: allows custom compression filters and fine-tuned gzip settings; avoids double-compression via configurable encodings.
• Risk: low; validated by added/updated unit tests.

[markt-asf]

Thanks for providing the PR. It has been very thought provoking.

I think we need to look at more than just GZip. Other compression algorithms are available and I think we need a more generic approach. I don't think we should be setting algorithm specific settings in the Protocol. I also don't think they should be set on CompressionCongfig. Speaking of CompressionConfig, are the new getters there used? I looked but couldn't see any calls to them.

I think we might need a new server.xml element for output compression (and possibly one for input compression too). With attributes for className, encoding and algorithm specific attributes. It should be possible to override the default gzip support.

The handling of custom InputFilters might provide some inspiration for OutputFilters.

There are some elements of the PR that can be used as is. I'll start cherry-picking those shortly.

[Long9725]

Apologies for the delayed response — I missed this review earlier. Thank you for the thoughtful feedback.

I agree that we should look beyond gzip and move toward a more generic compression approach. Supporting additional algorithms such as Zstandard was also one of the motivations behind this work. My intention was to approach this incrementally in two stages:

1. Improving gzip configuration support as a small and predictable step
2. Moving toward a more generic design to support multiple compression algorithms as a larger follow-up change

I split it this way because the first step felt relatively contained, while the second seemed likely to require broader architectural discussion and potentially significant changes depending on the preferred direction. Given your feedback, would you prefer this PR to remain focused on the incremental improvements, with the broader compression design handled separately, or should this PR evolve toward a more generic compression architecture?

Separately, regarding CompressionConfig — one reason I made changes there is that it is also used by the Spring Boot Tomcat integration. While investigating how to make these options configurable from Spring Boot, I found that Tomcat first needs to expose the relevant configuration properties before they can be surfaced on the Spring side.