Add deflate as a supported REST response encoding

[fishface60]

Some HTTP servers don't parse Accept-Encoding headers as they should and just assume that deflate is commonly available.

okhttp3 has built-in support for transparently adding gzip as an accepted encoding, and decoding the response body, which is how gzip previously Just Worked.

This built-in encoding handler is conditional on the user not passing in any Accept-Encoding headers, which is assumed to indicate that the caller intends to somehow handle the encoded response body themself.

We can implement our own transparent decoding support using the same mechanism that okhttp3 does internally and add an Interceptor callback that adds headers before the request and returns a new response with the encoding headers removed and the body wrapped in decoding readers.

This is strictly more correct than the okhttp3 built-in decoder because Content-Encoding can be a sequence of encodings applied in order that have to be decoded in reverse order.

I have submitted richardwilkes/gcs#889 to add support for uncompressed responses in GCS but it would be better if MapTool could also support deflate compressed responses.

Identify the Bug or Feature request

resolves #5015

Description of the Change

This customises the HTTP client instance to add an interceptor that adds extra headers to the request indicating it accepts gzip and deflate, and transparently decodes the result.

Possible Drawbacks

Request is doing more work so is slightly slower.

I could potentially have missed an edge case and cause HTTP requests to break for others.

Documentation Notes

None, gzip was transparently handled previously so users shouldn't need to be aware that it also handles deflate now.

Release Notes

• The REST family of macro functions now support handling responses that are compressed with the deflate algorithm.

---

This change is