content-encoding: fix Gzip test on non-linux hosts

The output test for Gzip encoding uses a hardcoded expected value,
however the Gzip header is unstable containing both a timestamp and an
OS ID field.

The timestamp field is apparently not set by the `deflate` crate but the
OS ID is, meaning this test consistently fails on systems other than
x86_64 Linux.

Here we just change the test to ignore the 10-byte header, rather than
trying to hack together a proper round-trip test in the absence of a
decoder method in the library crate.

src/content_encoding.rs

@@ -309,13 +309,18 @@ mod tests {
  .0
  .read_to_end(&mut encoded_content)
  .unwrap();
+
+ // The 10-byte Gzip header contains an OS ID and a 4 byte timestamp
+ // which are not stable, so we skip them in this comparison. Doing a
+ // literal compare here is slightly silly, but the `deflate` crate has
+ // no public decompressor functions for us to test a round-trip
  assert_eq!(
- encoded_content,
+ encoded_content[10..],
  vec![
- 31, 139, 8, 0, 0, 0, 0, 0, 0, 3, 179, 201, 40, 201, 205, 177, 179, 201, 72, 77, 76,
- 177, 179, 41, 201, 44, 201, 73, 181, 243, 72, 205, 201, 201, 87, 40, 207, 47, 202,
- 73, 177, 209, 135, 8, 217, 36, 229, 167, 84, 218, 217, 20, 160, 202, 21, 216, 217,
- 232, 67, 36, 244, 193, 166, 0, 0, 202, 239, 44, 120, 76, 0, 0, 0
+ 179, 201, 40, 201, 205, 177, 179, 201, 72, 77, 76, 177, 179, 41, 201, 44, 201, 73,
+ 181, 243, 72, 205, 201, 201, 87, 40, 207, 47, 202, 73, 177, 209, 135, 8, 217, 36,
+ 229, 167, 84, 218, 217, 20, 160, 202, 21, 216, 217, 232, 67, 36, 244, 193, 166, 0,
+ 0, 202, 239, 44, 120, 76, 0, 0, 0
  ]
  ); // Applied proper gzip encoding
  }