Problems with Content-Length and Transfer-Encoding

This could potentially be seen as a couple of different issues, but they're all tightly overlapping, and can probably all be solved with a common fix. This also overlaps with #2215.

Currently, Content-Length: 0 may be automatically applied to any 204 response (just like 101 responses in #2215). Also, other Content-Length headers can be set explicitly within a service, or be implied by a body with a KnownLength. A 204 response MUST NOT contain either Content-Length or Transfer-Encoding.

On the other hand, a 304 response will never have a body, but MAY contain either Content-Length or Transfer-Encoding. Currently, the only way to get a Content-Length header attached to a 304 response is to try to actually send a Body of that length.

The headers made in response to a HEAD request should match those which would have been made for a GET request. Currently, if a service attempts to force chunked encoding on what might otherwise imply a Content-Length header be added, GET requests will see Transfer-Encoding: chunked while a HEAD request receives Content-Length: .... It is not currently possible to set Transfer-Encoding on a response to a HEAD request.

It seems the things which need to be fixed are:

• For 204s, 100..199s, and any 2xx response made to a CONNECT request, any Content-Length or Transfer-Encoding header set by a service must be dropped. Further, neither header should be automatically added.
• Any Content-Length or Transfer-Encoding header set by a service for any kind of response should be handled the same for GET and HEAD requests.
• Any Content-Length or Transfer-Encoding header set by a service for a 304 response should be left alone. (perhaps unless a BodySize::Known greater than 0 conflicts with a Content-Length header, which could be an error?)

For reference, https://httpwg.org/specs/rfc7230.html#rfc.section.3.3

Start with the RFC 7230 section linked in the issue, then trace how services produce response headers for 204, 1xx, 2xx CONNECT, 304, GET, and HEAD responses. Done means applying the three checklist rules consistently, including preserving permitted headers for 304 responses and matching GET and HEAD behavior.