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

https://github.com/rubygems/rubygems/commit/716666f65f

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

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

https://github.com/rubygems/rubygems/commit/46258d6cb4

Previously, `rake install` or `rake update` would fail if there was a non-tar format `.gem` file in the current working directory.

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

Gem::Package::TarReader::Entry now raises EOFError or returns nil
appropriately based on Ruby core IO.read and IO.readpartial behavior.

Zlib will respond accordingly by raising Zlib::GzipFile::Error on EOF.

When verifying a gem or extracting contents, raise FormatError similar
to other cases of corrupt gems.

Addresses a bug where Gem::Package would attempt to call size on nil
instead of raising a more descriptive and useful error, leading users
to assume the problem is internal to rubygems.

Remove unused error class TarReader::UnexpectedEOF that was never raised
since the NoMethodError on nil would happen first. Use EOFError instead.

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

https://github.com/rubygems/rubygems/commit/6d9e8025dc