Enforce ruby and bundler versions

[sethboyles]

The Problem

There's some tricky behaviour with the CAPI pre-packaging/packaging process and how it uses Bundler that I think can be particularly confusing, especially to those new to contributing to CCNG that'd I'd like to document here and hopefully mitigate with this PR.

Cloud Controller must always use the default Bundler version with its Ruby version, or CAPI releases will not work on air-gapped environments.

This happens if a the BUNDLED WITH version in the Gemfile.lock is bumped beyond the default, meaning that when it comes time to run bundle in the packaging step, bundler will notice that it does not have the correct version, attempt to download the right version, and fail.

I think these issues can be mitigated by adding the Bundler and Ruby versions to our Gemfile.

Adding bundler to our Gemfile:

If you try to create a dev release with a different version (say you accidentally chruby'd 3.3 so now Bundler is 2.5.X), you get an error during prepackaging:

+ bundle package --all-platforms --no-install
Could not find compatible versions

Because the current Bundler version (2.5.18) does not satisfy bundler ~> 2.4.10
  and Gemfile depends on bundler ~> 2.4.10,
  version solving has failed.

Your bundle requires a different version of Bundler than the one you're running.
Install the necessary version with `gem install bundler:2.4.22` and rerun
bundler using `bundle _2.4.22_ package --all-platforms --no-install`
+ exit_code=6
+ set -e
+ '[' 6 == 0 ']'
+ sleep 1
+ '[' 6 '!=' 0 ']'
+ echo 'ERROR: Failed to run '\''bundle package'\'' after 3 attempts'
+ exit 6
':
              exit status 6

It also won't be possible to bump Gemfile.lock to a new BUNDLED WITH version during a bundle update.

Adding bundler to our Gemfile may allow us to use newer versions of Bundler than what's the Ruby version's default because now the Bundler gem will be vendored like the others and the compilation VM won't need to download it. But I'd have to test on an air-gapped env just to be sure.

That said, I did find this solution relatively inconsistent--there were times where I thought creating a new release would error out because of the Bundler version I had selected, and it was somehow able to succeed.

Adding Ruby version to our Gemfile

Because of the prepackaging step, creating a CAPI bosh release (in this context, usually for testing) is reliant on having the correct Ruby version selected. This might manifest in errors during runtime or compilation, but I've seen this fail most frequently because the wrong Bundler version would be inadvertently selected, and gems would be vendored/packaged with Bundler 2.5, which would hit this bug with Bundler 2.5.

That makes this a little redundant with adding the Bundler version to the Gemfile, but adding the Ruby version to the Gemfile will instead will fail quickly during prepackaging with a clear message:

Your Ruby version is 3.4.2, but your Gemfile specified 3.2.6
+ exit_code=18
+ set -e
+ '[' 18 == 0 ']'
+ sleep 1
+ for i in '{1..3}'
+ bundle config --local specific_platform true
+ bundle config --local path ./vendor/cache
+ bundle config set cache_all true
+ set +e
+ bundle package --all-platforms --no-install

It will also raise an error if someone tries to run CCNG tests (or bundle install, etc) with the wrong Ruby version.

• I have reviewed the contributing guide

• I have viewed, signed, and submitted the Contributor License Agreement

• I have made this pull request to the main branch

• I have run all the unit tests using bundle exec rake

• I have run CF Acceptance Tests

[johha]

I've looked around a bit and could not find any big ruby project which specifies the bundler version in the Gemfile but also don't see any harm in it. For air-gapped envs this could be beneficial to detect version mismatches earlier. From my point this can be merged.