Bundler treats "lockfile" as a special value for the version setting,
meaning "use the version recorded in BUNDLED WITH". BundlerVersionFinder
was passing the raw string to Gem::Version.new and raising ArgumentError
both from the env var added in #9538 and from .bundle/config.

https://github.com/ruby/rubygems/commit/6576bb8e53

Bundler::Settings resolves the `version` setting from the BUNDLE_VERSION
environment variable, but Gem::BundlerVersionFinder only consulted the
.bundle/config file. As a result `BUNDLE_VERSION=system` was ignored at
activation time and a lockfile-pinned bundler installed globally won
out over the default gem.

https://github.com/ruby/rubygems/issues/9534

https://github.com/ruby/rubygems/commit/c652c233aa

- ### Problem

  If you have a `version` in your config file (this feature was
  introduced in #6817), then running any `bundle` command will
  make Bundler re-exec and ultimately run the `bundle` binstub twice.

  ### Details

  When the `bundle` binstub gets executed, a `require "bundler"` is
  evaluated. RubyGems tries to require the `bundler.rb` file from
  the right `bundler` gem (in the event where you have multiple
  bundler versions in your system).
  RubyGems will prioritize a bundler version based on a few
  heurisitics.

  https://github.com/ruby/rubygems/blob/b50c40c92abb00bb172f1579356cc73c242b1849/lib/rubygems/bundler_version_finder.rb#L19-L21

  This prioritize logic doesn't take into account the bundler version
  a user has specific in this config. So what happens is:

  1. User execute the `bundle` binstub
  2. `require 'bundler'` is evaluated.
  3. RubyGems prioritize activating the bundler version specified
     in the Gemfile.lock
  4. The CLI starts, and [Auto switch kicks in](https://github.com/ruby/rubygems/blob/b50c40c92abb00bb172f1579356cc73c242b1849/bundler/lib/bundler/cli.rb#L81). Bundler detects that
     user specifed a version in its config and the current Bundler
     version doesn't match.
  5. Bundler exit and re-exec with the right bundler version.

  ### Solution

  This patch introduce two fixes. First, it reads the bundler config
  file and check for the local config first and then the global
  config. This is because the local has precedence over global.

  Second, the prioritization takes into account the version in config
  and let RubyGems activate the right version in order to prevent
  re-exec moments later.

  Finally, I also want to fix this problem because its a step toward
  fixing https://github.com/ruby/rubygems/issues/8106. I'll open
  a follow up patch to explain.

https://github.com/ruby/rubygems/commit/d6e0f43133

If we use "system" variable in BUNDLE_VERSION on Bundler configuration,
we can use bundler version provided by system installation.

But the current logic returns the first activated version of bundler
like 2.7.2. It makes to confuse users.

https://github.com/ruby/rubygems/commit/4eb66d9549

This specifies the lockfile location. This allows for easy support
of different lockfiles per Ruby version or platform.

https://github.com/ruby/rubygems/commit/b54d65bc0a

Co-authored-by: Sutou Kouhei <kou@cozmixng.org>
Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>

This is useful, in case you're using Docker, and an upstream
Dockerfile sets BUNDLER_VERSION to something you don't want.
It's impossible to unset it... only override to be the empty
string.

https://github.com/ruby/rubygems/commit/ffa3eb9ac6

https://github.com/rubygems/rubygems/commit/30dce3f87d

https://github.com/rubygems/rubygems/commit/56ce2a6445

https://github.com/rubygems/rubygems/commit/10c26a483d

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