This gets in the middle if we ever start allowing to build as if using a
different RubyGems version than the one being run.

This could be useful to make `gem rebuild` a little more usable, and
it's already done by Bundler specs which already make this method a noop
when they need this.

I'm not sure forcefully setting this, even if user explicitly specified
something else is helpful.

Since this could potentially prevent gems explicitly setting a constant
RubyGems version from building, I changed the error of incorrect
RubyGems version from a hard error to a warning, since it will start
happening in those cases if we stop overwriting the version.

https://github.com/rubygems/rubygems/commit/45676af80d

https://github.com/rubygems/rubygems/commit/c4e75b9f74

This is to prevent a malicious gem from causing a denial of service by
including a very large metadata or checksums file,
which is then read into memory in its entirety just by opening the gem package.

This is guaranteed to limit the amount of memory needed, since
gzips (which use deflate streams for compression) have a maximum compression
ratio of 1032:1, so the uncompressed size of the metadata or checksums file
will be at most 1032 times the size of the (limited) amount of data read.

This prevents a gem from causing 500GB of memory to be allocated
to read a 500MB metadata file.

https://github.com/rubygems/rubygems/commit/a596e3c5ec

https://github.com/rubygems/rubygems/commit/241d0aafcd

Most of the calls to `FormatError.new` pass `@gem` for the second argument, which has a `path` method.

But in one case—on package.rb:691 in `verify_gz`, the `source` argument is a `String`.

So if there's ever a GZip decode error when attempting to read the contents of the `data.tar.gz` file, instead of reporting the underlying GZip error (which might be something like "unexpected end of file"), we would report instead a NoMethodError coming from package.rb

```
Exception while verifying sorbet-0.5.11301.gem
ERROR:  While executing gem ... (NoMethodError)
    undefined method `path' for "data.tar.gz":String

        @path = source.path
                      ^^^^^
```

There are two ways to fix this:

1. Make `FormatError#initialize` aware of the fact that `source` might sometimes be a `String`
2. Make the call to `FormatError.new` in `verify_gz` pass `@gem` instead of `entry.full_name`.

I've chosen 1 because I think it's more useful to see "unexpected end of file in data.tar.gz" instead of "unexpected end of file in sorbet-0.5.11301.gem." The end of file **is actually** in data.tar.gz, not in the gem file itself, which was decoded successfully.

https://github.com/rubygems/rubygems/commit/fd5cb7396f

This reverts commit 01f9766aa05182a7bbdc914a5dcd8a36ebade861.

For now, on a small rails app I have hanging around:

```
==> memprof.after.txt <==
Total allocated: 872.51 MB (465330 objects)
Total retained:  40.48 kB (326 objects)

==> memprof.before.txt <==
Total allocated: 890.79 MB (1494026 objects)
Total retained:  40.40 kB (328 objects)
```

Not a huge difference in memory usage, but it's a drastic improvement
in total number of allocations.

Additionally, this will pay huge dividends once
https://github.com/ruby/zlib/pull/61 is merged, as it will allow us to
completely avoid allocations in the repeated calls to readpartial,
which currently accounts for most of the memory usage shown above.

https://github.com/rubygems/rubygems/commit/f78d45d927