Bump Rubygems to 3.3.22

[jeffwidman]

Bump Rubygems to 3.3.22:
https://github.com/rubygems/rubygems/blob/master/CHANGELOG.md#3322--2022-09-07

There's some prior history here:

1. Originally bumped from 3.2.20 to 3.3.11 in Update RubyGems and use --no-document for updating it #5035. That changed how bundler
   version detection worked, which caused some problems.
2. We attempted to workaround the issue in
   Set BUNDLER_VERSION to the specific installed version in native helpers #5044, but that
   wasn't sufficient.
3. So in Rollback RubyGems from 3.3.11 to 3.2.20 #5048 we
   rolled back to 3.2.20
4. However, as part of the Ruby 3.1 upgrade, we have to bump to
   Rubygems >=3.3.3... so we need to figure out a fix.
5. Now that updater is merged into core, we can have the full test
   suite checking the results, and don't have to bump in core, then
   pull into updater and see if it passes a separate CI... the
   two-step dance was the reason why this wasn't caught in the original
   core PR but instead merged and then reverted.
6. I am reasonably sure that @deivid-rodriguez figured out a way around
   the Bundler version difficulty in
   Decouple Bundler versions #5513, so this PR
   requires that to land first.
7. Originally I had the Rubygems upgrade bundled as part of the Ruby 3.1
   upgrade, but now that we have a better understanding of what's
   happening, we should be fine to do these changes independently...
   which lets us more easily debug if we do happen to encounter problems.
   So I am splitting this out as a separate PR.

[jeffwidman]

This depends on #5513, the diff will get much smaller once that is merged.

[jeffwidman]

I discovered over in #5447 (comment) before I split out the rubygems upgrade separate from the ruby upgrade:

The failing test for bundler is because dependency_rubygems_uri now points at an unstubbed URL: "https://rubygems.org/api/v1/versions/bundler.json"

However, I'm not actually sure what the expected behavior is here... I was surprised that Rubygems is suddenly making an additional call to this URL, so I'm a little hesitant to just stub it out until we confirm for sure that this is expected behavior.

Especially given @deivid-rodriguez 's comments in 629d1f0 (part of #5509):

During the migration from Ruby 2.6 to Ruby 2.7 (first Ruby which
includes Bundler 2.x by default), this spec caused some issues because
dependabot would issue a call to the RubyGems dependency API to figure
out information about Bundler. But this is not needed these days and it
probably wasn't since the beginning, because dependabot should always
use the running Bundler version information in this case, no need to
query the API.

Given that he is an active committer to RubyGems, he'll know way more about the expected behavior here than I do. So I will wait to proceed with a fix until he has a chance to look at this... if it's expected, then the URL just needs stubbing, otherwise if unexpected then we may need to update Dependabot's usage of Bundler or even fix a bug in rubygems...

[deivid-rodriguez]

So, the fix for this is 0dfa6ff. So rebasing this on top of #5509 should do the trick I think!

The explanation goes as follows:

0dfa6ff9131d7dd5c6b33608671c084f775c669d is a change to support recent Bundler versions (at least 2.3.20) and this PR is not explicitly bumping those versions. So why it's hitting us here? I think that's because RubyGems 3.3.22 also ships with Bundler 2.3.22 as a default gem. An since that version is newer than the one we currently install explicitly (2.3.14), Dependabot is now picking that up.

[jeffwidman]

Rebased on top of main now that #5509 and #5513 are merged.