Yum proxy needs to be more lenient about gzip encoding

Create a yum proxy of https://www.nasm.us/pub/nasm, and then request metadata through it:

stable/linux/repodata/12b939252f619201cf76ec407f466888e1947d40f1858f121a47903fb5b0c17c-primary.xml.gz

This download will fail with a 404. The log shows:

2020-06-19 17:26:45,607+1000 ERROR [qtp12776417-202] *UNKNOWN org.sonatype.nexus.repository.yum.internal.metadata.YumAbsoluteUrlRemover - Failed to fix absolute urls for file stable/linux/repodata/12b939252f619201cf76ec407f466888e1947d40f1858f121a47903fb5b0c17c-primary.xml.gz and blob tmp$dc6f4eca-775f-4df6-adbb-5a1264221f0e with reason: {}
java.io.IOException: Input is not in the .gz format

The cause of this is that the remote has "content-encoding" set to gzip:

< HTTP/1.1 200 OK
< Date: Fri, 19 Jun 2020 15:24:34 GMT
< Server: Apache/2.4.43 (Fedora)
< Strict-Transport-Security: max-age=7776000
< Last-Modified: Wed, 26 Dec 2018 13:46:26 GMT
< ETag: "bce-57ded0e6d536c"
< Accept-Ranges: bytes
< Content-Length: 3022
< Connection: close
< Content-Type: application/gzip
< Content-Encoding: gzip

But in fact, it is just a gzip file, the stream itself is not compressed. So jetty decompresses it, and then a plain XML file (not gzipped) is delivered to our code, which then tries to decompress it.

This is a bug in the remote site. However, we should be more lenient in our handling of this. Download of the same file works fine with yum.

Expected: If an xml.gz file delivered from a remote yum repository's metadata is not gzipped, we should fall back to trying to process it as plain XML.