Add a test that important files come early in extracted images

[imjasonh]

In a few places, we make some assumptions that calling ggcr's mutate.Extract and scanning for specific files will not end up reading the entire image contents.

For a refresher, mutate.Extract returns a ReadCloser that can be passed to tar.NewReader and iterated over to get file contents in a layered image. It reads the top-most layer first, in order, collects .wh. files to possibly whiteout lower-layered file paths, then proceeds down the layers until the end.

It's relatively common to Extract, iterate through files until you find one you like, and rc.Close(), which exits the goroutine. If you were reading a remote.Image over the wire from the registry, or a local tarball.Image or daemon.Image, you'll only read layers until you find the one you care about, and can save quite a lot of time and resources if the file you care about is "early" in the extracted tar.

Apko purposefully puts its "first-party" files (those not from packages) into the top-most layer, upfront in the tar, to make these operations as cheap as possible.

This has historically just been a convention, but it's a nice convention, and I thought it might be useful to have a test that ensures we don't accidentally undo that in the future, e.g., if we refactor how layering works, or add other layering strategies.

The test as-is checks that these files are found in the first ~4KB of the image, rather than at the end of a possibly gigantic tar stream.

[jonjohnsonjr]

I'm ok with this mostly because I want to know if it changes but I'd be willing to t.Skip() this test if it becomes a problem.