Improve WebSocket compression internals and resource cleanup

[mkurz]

This is a follow-up to

• Add server-side WebSocket compression #1114

that addresses review feedback and improves the WebSocket compression implementation without changing its public API or configuration.

The changes:

• Reuse 8 KiB buffers in the inflater and deflater flows instead of allocating a buffer for every operation.
• Accumulate split physical-frame data without repeatedly copying previous fragments, then compact it once before compression or decompression.
• Reject empty client_max_window_bits and server_max_window_bits values.
• Handle custom WebSocketSettings implementations without an unsafe cast.
• Process repeated Sec-WebSocket-Extensions headers directly.
• Align the disabled compression settings with the reference.conf default for max-allocation.
• Replace mutable global inflater/deflater test factories with factories scoped to each materialized flow.
• Verify that every created Inflater and Deflater is released exactly once.

Resource cleanup is tested for normal completion, upstream failure, downstream cancellation, protocol errors, and incomplete compression state.

The wire and stream semantics for incomplete compressed messages intentionally remain unchanged. This follows Netty’s compression-layer behavior: incomplete codec state is discarded during connection termination while its resources are released. Any future change to truncated-message handling should be designed as a general WebSocket framing change covering both compressed and uncompressed messages.

Testing

• WebSocketServerSpec
• sbt applyCodeStyle
• sbt checkCodeStyle
• sbt +mimaReportBinaryIssues
• sbt validatePullRequest

References

• Please add support for WebSocket compression #61
• Add server-side WebSocket compression #1114

[mkurz]

I also pushed commit which increases the default WebSocket decompression limit from 64 KiB to 256 KiB, as agreed during the review of #1114 (comment).
The commit updates both reference.conf and the internal disabled-settings baseline. The limit remains configurable, and setting it to 0 disables it.
For comparison, Netty exposes an equivalent maxAllocation setting but defaults it to 0 (unlimited). Pekko HTTP applies its limit cumulatively to the complete logical WebSocket message, including continuation frames.
The focused WebSocketServerSpec still passes with all 38 tests successful.

[pjfanning]

lgtm