Even if they don't match the current Ruby version, they could still work
in other rubies. So it's better to keep them.

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

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

https://github.com/rubygems/rubygems/commit/0c3a65871a

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

The original implementation of this flag was too naive and all it did
was restricting gems to locally installed versions if there are any
local versions installed.

However, it should be much smarter. For example:

* It should fallback to remote versions if locally installed version
  don't satisfy the requirements.
* It should pick locally installed versions even for subdependencies not
  yet discovered.

This commit fixes both issues by using a smarter approach similar to how
we resolve prereleases:

* First resolve optimistically using only locally installed gems.
* If any conflicts are found, scan those conflicts, allow remote
  versions for the specific gems that run into conflicts, and
  re-resolve.

https://github.com/rubygems/rubygems/commit/607a3bf479

Co-authored-by: Gourav Khunger <gouravkhunger18@gmail.com>

Instead of having to do a complete pass after resolve.

To do this, we add to the ruby group all the platform specs with the
same dependencies as the ruby specs.

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

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

While working on locking multiple platforms by default, I got an
infinite resolution loop in one of our resolver specs.

The culprit ended up being that when dealing with lockfile specs with
incomplete dependencies (spec appears in lockfile, but its dependencies
don't), those specs were not being properly expired and that tripped up
resolution.

The issue for some reason only manifests when dealing with multiple
lockfile platforms, that's why it only manifested when working on
locking multiple platforms by default.

https://github.com/rubygems/rubygems/commit/4ca72913bb

This reverts commit 69580f8b72f41c58cae57d1ada4db909922b3891.

Bundler is very conservative by default, trying to preserve versions
from the lockfile as possible, and never downgrading them. However, when
it runs into a resolution error, it still tries to find a valid
resolution.

This fallback behavior was too "brute-force" though, completely
unrestricting any gem found in the resolution conflict, and that could
lead to direct dependencies being downgraded in some edge cases.

Instead, unlock things a bit more carefully:

* First try unlocking fully pinned indirect dependencies, but leave a
  lower bound requirement in place to prevent downgrades.
* Then try unlocking any fully pinned dependency, also leaving a lower
  bound requirement in place.
* Finally completely unrestrict dependencies if nothing else worked.

https://github.com/rubygems/rubygems/commit/7f55ed8302