Resolver had internal logic to prioritize locked versions when sorting
versions, however part of it was not being actually hit because of how
unlocking worked in the resolver: a package was allow to be unlocked
when that was explicit requested or when the list of unlocks was empty.
That did not make a lot of sense and other cases were working because
the explicit list of unlocks was getting "artificially filled".

Now we consider a package unlocked when explicitly requested (`bundle
update <package>`), or when everything is being unlocked (`bundle
install` with no lockfile or `bundle update`).

This makes things simpler and gets the edge case added as a test case
working as expected.

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

So that we don't need to reverse the Array.

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

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

We do that when first caching versions, and then it's no longer
necessary.

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

https://github.com/rubygems/rubygems/commit/13294528c4

When the latest allowed minor of `dep` adds a new dependency, that new
dependency would be incorrectly resolved to the latest minor of the
first major version.

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

Prereleases are NOT considered even when the dependency specification
includes a prerelease segment, if the dependency is not locked. To me
that doesn't make sense, because I could create a Gemfile with say gem
"rails", ">= 7.0.0.beta1" and I'd expect prereleases considered there
even if there's no lock file yet.

Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>

https://github.com/rubygems/rubygems/commit/390e3e1ebd

Passing this flag allows bumping to the current version, even if that
version is prerelease. This works in concert with the current flags.

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

https://github.com/rubygems/rubygems/commit/6624474c5a