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

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

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

Closes https://github.com/rubygems/rubygems/pull/8068

This issue only occurs if the underlying stub is a gem stub:
https://github.com/Earlopain/rubygems/blob/f56098d8a193dcb94584d721e82b8cff397e5265/bundler/lib/bundler/stub_specification.rb#L109-L112

https://github.com/rubygems/rubygems/commit/9b0152b3d5

https://github.com/rubygems/rubygems/commit/55649cd09b

This gets the specs passing, and handles the fact that we expect
checkums to be pinned only to a particular source

This also avoids reading in .gem files during lockfile generation,
instead allowing us to query the source for each resolved gem to grab
the checksum

Finally, this opens up a route to having user-stored checksum databases,
similar to how other package managers do this!

Add checksums to dev lockfiles

Handle full name conflicts from different original_platforms when adding checksums to store from compact index

Specs passing on Bundler 3

https://github.com/rubygems/rubygems/commit/86c7084e1c

1. Use the checksum provided by the server if provided: provides security
knowing if the gem you downloaded matches the gem on the server

2. Calculate the checksum from the gem on disk: provides security knowing
if the gem has changed between installs

3. In some cases, neither is possible in which case we don't put anything
in the checksum and we maintain functionality as it is today

Add the checksums to specs in the index if we already have them

Prior to checksums, we didn't lose any information when overwriting specs
in the index with stubs. But now when we overwrite EndpointSpecifications
or RemoteSpecifications with more generic specs, we could lose checksum
info. This manually sets checksum info so we keep it in the index.

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

We were setting the wrong `extension_dir` for git specs stubs

Additionally, the call to `self.extension_dir` was loading the
remote spec, which was avoidable since the stub had an extension dir
(and in fact its #gem_build_complete_path does exactly what we want
anyway)

Finally, now set the base_dir when loading the remote_spec from a
stub specification, since the git source sets the base dir for stubs
based on where the spec _will_ be installed to, and we want to preserve
that so the base_dir for the loaded spec & the stub are the same

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

The installer is actually rewriting the spec's full gem path to be the
one of the newly installed gem, however the accessor was not properly
working for `StubSpecification` instances, and default gems are always
of this type, because they are always present locally.

Fix the accessor to properly update the underlying full specification.

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

This change was never covered with a spec, and we have recently covered
the case of partially deleted gems with specs and it works fine
(installation is "auto-healed").

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