cmd/distpack: consider the use of zopfli

[dsnet]

There is benefit to providing releases compressed with gzip over formats like zstd or xz.
While the other formats provide better compression ratios, they are seldom used in comparison to the ubiquitous nature of gzip.
zstd is well-positioned to take over as the defacto compression format, but that probably won't happen for another decade.

That said, we can still do better within gzip itself.

If we're willing to burn CPU and depend on cgo,
we can use zopfli to produce a close-to-optimal gzip file.
Note that zopfli is not a new compression format, but a clever algorithm that searches for the optimal selection of LZ77 matches and block splits in the existing gzip format.

For example, with go1.21.0.linux-amd64.tar.gz, the current size is 63.4MiB.
But after 15 minutes of single-threaded execution on a Ryzan 5900x with zopfli,
the file can be reduced to 59.7MiB, which is a savings of ~6%.

[cespare]

On one hand, this seems like a clear win. On the other, it seems ridiculous to participate in this herculean effort to push 90s tech to the utmost limit when much, much better options are available in 2023. I filed #62446 to register this view, though my hopes for uptake are not high.

[cherrymui]

cc @rsc @golang/release

[dsnet]

For the record, I like @cespare's proposal in #62446. I'm a fan of zstandard. Providing zstd releases alongside gzip might obviate the need for this, although they're not mutually exclusive solutions. Burning 15 minutes of CPU would save 3.5TB of bandwidth if there was a 1M downloads.

[heschi]

I think if we do anything here it'll probably be to add zstd archives. Closing for now.