Add tests for serving content from large zip files with lots of metadata

Summary

Before upgrading to Go 1.17.x we should ensure we have some level of testing serving from large zip archives with lots of metadata.

See gitlab-com/gl-infra/production#5521 (comment 676483734) for more details.

An example of expected number of requests can be found in the test introduced in !646 (merged). Original explanation from !646 (comment 776032245):

The first 3 requests are:

* `bytes=0-0` used for getting the size of the entire archive (via `Content-Length` or `Content-Range`).
* `bytes=4815-5838` `zip.readDirectoryEnd` (https://github.com/golang/go/blob/go1.17.5/src/archive/zip/reader.go#L536) attempts to find the [EOCD](https://en.wikipedia.org/wiki/ZIP_(file_format)#End_of_central_directory_record_(EOCD)).
* `bytes=5566-5838` is a request for the [central directory](https://en.wikipedia.org/wiki/ZIP_(file_format)#Central_directory_file_header), using the offset and length from the EOCD.

The archive contains 4 files. Each file requires a fetch for the [data descriptor](https://en.wikipedia.org/wiki/ZIP_(file_format)#Data_descriptor) and then a full read of the content of the file.

1. `bytes=0-29`, `bytes=43-47`
1. `bytes=64-93`, `bytes=111-160`
1. `bytes=177-206`, `bytes=225-371`
1. `bytes=388-417`, `bytes=437-554`

This brings the total to 11 range requests.

In contrast to Workhorse, it only needs 2 requests for the archive open (EOCD, central directory) and only 1 additional request for the entire read. It achieves this by not specifying `range-end`. The file's (data descriptor, data content) layout for each file is sequential, so it doesn't need to make individual requests.

Fortunately, for pages, this isn't actually a concern, because each request for a file only fetches one file. It could probably be more efficient in regards to the small single request for the data descriptor, but this data is cached, so likely not a problem.

This number has the potential to change based on how we perform reads, but for these 4 files, the request count should never be turned up to more than 11.