CXF-8096: Fix LoggingFeature blocking read on streaming responses

[gnodet]

Summary

Fixes CXF-8096 — LoggingFeature blocks client reads on streaming responses.

Root cause: WireTapIn interceptor eagerly reads the entire input stream via IOUtils.copyAtLeast() before the application can process it. For streaming responses (e.g., StreamingOutput with chunked transfer), this blocks the client from reading data incrementally.

Fix:

• Introduces TeeInputStream — wraps the input stream and copies data to the logging cache as it flows through (up to the configured limit), without blocking
• WireTapIn now uses TeeInputStream instead of the eager copyAtLeast + SequenceInputStream approach
• LoggingInInterceptor defers logging to a stream-close callback when the stream hasn't been consumed yet (streaming case), while preserving immediate logging for cases where the body is already consumed (e.g., SOAP/JAX-WS where unmarshal happens before PRE_INVOKE)

Key files:

• TeeInputStream.java — new class, copies reads to CachedOutputStream transparently
• WireTapIn.java — uses TeeInputStream instead of eager read
• LoggingInInterceptor.java — deferred logging via close callback
• Test updates to consume streams before asserting log events (reflecting the new non-blocking behavior)
• New streamingInputShouldNotBlockRead test verifying the streaming scenario

Supersedes #574 (which was test-only with no fix).

Test plan

• All existing logging module tests pass (124 tests)
• New streaming test (streamingInputShouldNotBlockRead) verifies non-blocking behavior
• CI pipeline

🤖 Generated with Claude Code