Do not send compression as acceptable encoding

When a BMC can compress a response, the internal server... or any
intermediate proxy may change a "Strong" ETag to a "Weak" ETag, as
the strength of the ETag represents the byte-by-byte consistency of the
response body.

Compressed responses may differ slightly, especially if different encoding
is used or negotiated. This is problematic when a resource expects a
follow-up request or action to contain a "Strong" ETag as it is the client
certifying it understood the prior precise state.

We no longer request opportunistic response encoding, and expressly request
responses are not modified or compressed by the intermediate server, which
should have a minimal impact to use and provide a higher level of BMC
interaction consistency.

Change-Id: Idb2d6bee96bd23cfc4fb8f014661231766998781
(cherry picked from commit 51dacf272f)
(cherry picked from commit 021e0175e2)

releasenotes/notes/do-not-offer-compression-encoding-884ca8a7458cb096.yaml

@@ -0,0 +1,16 @@
+---
+fixes:
+  - |
+    Fixes unreliable behavior with ETag interactions with some BMCs as
+    opportunistic use of compressed responses may cause the BMC to change
+    an ETag response to "Weak", which is to be expected as an ETag represents
+    an absolute byte-by-byte response consistency, and compression cannot
+    reliably honor that contract. Introduction of a client perceiving a
+    "Weak" ETag may not be expected by the server, and the server may reject
+    responses because the ETag is not a "Strong" ETag when we respond or
+    interact with a resource.
+
+    As a result, requests no longer offer oppurtunistic compression
+    of responses as an acceptable possibility, which overall has minimal
+    impact, espescially when compared to the value of consistent BMC
+    behavior and interaction.