Optimize local base image support: more efficient layer processing

[TadCordle]

Following up #1906.

• Multi-threaded layer compression
  • First pass (Parallelize local base image compression #2022)
  • Separate build steps to allow pushing layers immediately after compressing (Allow pushing local base image layers immediately after compressing #2144)

Old ideas that we don't want to do anymore:

• When extracting the tar, process each entry without writing them to disk (conflicts with caching mechanism)
• Instead of computing the layer digest and then pushing to a registry, push base image layers while compressing on-the-fly (Add ExtractTarStep and SaveDockerStep #1906 (comment)) (conflicts with caching mechanism)
• Untar docker save output directly instead of writing to disk first (i.e. docker save | tar -xf -) (Doesn't seem to save time, and hurts code readability)
• Use BEST_SPEED while gzipping instead of the default compression method (faster compression, but slows down push steps since blobs are larger)

[TadCordle]

For the record, I tried "Untar docker save output directly instead of writing to disk first", and it doesn't seem to save much time, if any (my initial experiment seemed to have saved time, but I can't reproduce it, even after clearing Jib's cache). It makes the code harder to read as well, since DockerClient, TarExtractor, and LocalBaseImageSteps need to be more tightly connected, so I think we can skip this one.

[TadCordle]

I also just tried using BEST_SPEED for layer compression. The results are sort of what I expected; the layer compression executes faster, so stuff like jibDockerBuild and jibBuildTar seems to be slightly faster overall. But the faster compression also results in larger blobs, which means pushing to a registry is slower. In that case this seems like it's not worth it since it will actually cause a slowdown for pushing to registries, especially for users with weaker connections.

[loosebazooka]

Should we make it configurable?

[TadCordle]

I don't think it's worth adding an extra configuration for it. The speed difference is pretty small anyway, and it's only when the image hasn't been cached yet.