Changed HttpLoggingPolicy to ensure a response is logged even if its body is never consumed by a client.

[vcolin7]

Currently, the HttpLoggingPolicy.LoggingHttpResponse class we use for logging a response will only log when either its Flux<ByteBuffer> getBody() or BinaryData getBodyAsBinaryData() methods get called (I assume to avoid eagerly buffering the response body). This causes a situation where policies such as BearerTokenAuthenticationPolicy don't log the response because they don't care about accessing the body but only the headers.

We're changing the logic in HttpLoggingPolicy to log the response no matter if the body is accessed or not. If the HttpLogLevel does not include the body (e.g. HEADERS), then it will not be consumed eagerly, otherwise we will include it in the log. We assume body logging is used in non-production scenarios, as it is more resource intensive, and it usually is enabled only when debugging issues.

As for tests, there are still a few failing ones, so I'll spend some time this week fixing that scenario.

[lmolkova]

We should ensure we close/consume bodies whenever possible because, orthogonal to logging, this signals underlying HTTP client implementation that response is consumed and it can return the underlying connection to the pool where it can be used for other requests.

Not closing the response body leads (orthogonally to logging) to connection staying 'busy' waiting for someone to consume the response, creating a bottleneck for the application.

While I have no objections eagerly buffering when request/response body logging is enabled, I believe we need to solve a bigger problem (if) we leak connections.

[azure-sdk]

API change check

API changes are not detected in this pull request.