Guard header copy against committed response in NettyRoutingFilter

[adityaanikam]

Fixes gh-4270

Problem

NettyRoutingFilter copies filtered response headers back onto the
client response near the end of filter():

response.getHeaders().remove(HttpHeaders.TRANSFER_ENCODING);
...
response.getHeaders().addAll(filteredResponseHeaders);

If the response has already been committed elsewhere in the filter
chain before routing completes, AbstractServerHttpResponse#getHeaders()
returns a cached ReadOnlyHttpHeaders wrapper instead of the mutable
headers map. Calling remove(...) or addAll(...) on that wrapper
throws UnsupportedOperationException, which surfaces as an error
signal on the filter chain instead of the response completing
normally.

Fix

Guard the header-copy step with response.isCommitted(). Once a
response is committed, headers can no longer reach the client
regardless, so skipping the copy is safe and matches an existing
precedent already in the test codebase
(BaseWebClientTests#modifyResponseFilter, which uses the same
isCommitted() check before touching response headers).

Testing

• Added NettyRoutingFilterTests#routingAfterResponseAlreadyCommittedDoesNotThrow,
  which pre-commits a MockServerWebExchange and asserts
  nettyRoutingFilter.filter(...) completes normally instead of
  erroring.
• Full NettyRoutingFilterTests suite passes.
• Verified with a negative control: reverting only the fix (keeping
  the new test) reproduces the exact reported
  UnsupportedOperationException at
  ReadOnlyHttpHeaders.remove(ReadOnlyHttpHeaders.java:166), matching
  the original issue's stack trace. Restoring the fix passes cleanly.

[HDPark95]

filteredResponseHeaders.remove(TRANSFER_ENCODING) (L182) is a no-op: the enclosing if already requires !filteredResponseHeaders.containsHeader(TRANSFER_ENCODING). The old line mutated response.getHeaders(), so this drops the scrub rather than guarding it.

Checked on main: a probe that presets Transfer-Encoding on the response and routes to a Content-Length upstream passes on main and fails with this patch, leaving both headers set. Keeping response.getHeaders().remove(...) inside your else branch preserves it.

Prior art on the same guard: #4115.

[adityaanikam]

Good catch, thanks you're right on both counts. The enclosing if already guarantees filteredResponseHeaders has no Transfer-Encoding, so removing it there does nothing, and the original line was scrubbing a stale header off the downstream response, which my change dropped.

Pushed a fix: response.getHeaders().remove(...) is restored as it was, with the whole block moved inside the not committed branch so it still can't touch a ReadOnlyHttpHeaders.

I also added a test matching the probe you described it presets Transfer-Encoding on the response and routes to an upstream answering with Content length. Reverting just the source change makes it fail with both headers still set.