content-length disincluded on streamed responses

Several years there was an issue with content-length being incorrect on streamed responses. This was causing clients, e.g. dnf to fail (which they should). The content length was wrong because it was the length of the encoded content received from the upstream payload, yet when we sent the payload to the client (our response) it isn't encoded the same.

The bugfix put in place was this.

If I read this right, on streamed responses we never include content-length. That seems wrong when there are cases where we can.

What if instead of disabling the Content-Length header by adding it to the hop_by_hop list of headers that we ignore, instead, we add only disable Content-Length in cases where Content-Encoding is also specified.

Start by reviewing commit 4816f3326879be54da0ac4577a44ba35b4d69de5 and the streamed-response header handling it changed. Trace how Content-Length and Content-Encoding are processed for streamed responses; done means Content-Length is retained when it accurately describes the client payload and omitted when encoding makes it unreliable.