In a `bundler/setup` context, we only want to load the plugins for gems
present in the $LOAD_PATH. In that context, `Gem.load_env_plugins` does
the trick just fine.

We don't want any of the globally installed gems to load anything an
"pollute" this environment so we stub `Gem.load_plugins` as a no-op.

There was some `Bundler::Installer` code though using
`Gem.load_plugins`. I'm not really sure about the usefulness of that
code, but since it's not the point of this PR to question it, I rewrite
it to avoid using `Gem.load_plugins`.

7649: Fix resolving specs when run against a dev ruby snapshot r=deivid-rodriguez a=deivid-rodriguez


<!--
Thanks so much for the contribution!

If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.

To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->

### What was the end-user or developer problem that led to this PR?

The problem is that in some dev ruby builds, `RUBY_PATCHLEVEL` is `-1`, so the spec crashes because of an ill-formed requirement.

See for example https://github.com/rubygems/rubygems/pull/3077/checks?check_run_id=457988784.

<!-- Write a clear and complete description of the problem -->

### What is your fix for the problem, implemented in this PR?

<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->

My fix is to change the spec to respect a `RUBY_PATCHLEVEL` equal to `-1`, by reusing code that handles that case.

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

In some dev builds, `RUBY_PATCHLEVEL` is `-1`, so the spec crashes
because of an ill-formed requirement.

7644: Unfreeze dependency hashes r=deivid-rodriguez a=deivid-rodriguez



<!--
Thanks so much for the contribution!

If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.

To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->

### What was the end-user or developer problem that led to this PR?

<!-- Write a clear and complete description of the problem -->

Running `bin/rake spec:deps` from jruby crashes with:

```
rake aborted!
FrozenError: can't modify frozen Hash
/path/to/bundler/spec/support/rubygems_ext.rb:36:in `dev_setup'
/path/to/bundler/Rakefile:29:in `block in <main>'
/path/to/bundler/Rakefile:14:in `block in invoke'
/path/to/bundler/Rakefile:13:in `invoke'
/path/to/bundler/spec/support/rubygems_ext.rb:98:in `gem_load_and_activate'
/path/to/bundler/spec/support/rubygems_ext.rb:45:in `gem_load'
Tasks: TOP => spec:deps
(See full trace by running task with --trace)
```

### What is your fix for the problem, implemented in this PR?

<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->

Unfreeze the hashes, since we are modifying them.

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

These hashes are actually modified. For example, to exclude some
dependencies under jruby.

So they should not be frozen.

Without this, running `bin/rake spec:deps` from jruby crashes with:

```
rake aborted!
FrozenError: can't modify frozen Hash
/path/to/bundler/spec/support/rubygems_ext.rb:36:in `dev_setup'
/path/to/bundler/Rakefile:29:in `block in <main>'
/path/to/bundler/Rakefile:14:in `block in invoke'
/path/to/bundler/Rakefile:13:in `invoke'
/path/to/bundler/spec/support/rubygems_ext.rb:98:in `gem_load_and_activate'
/path/to/bundler/spec/support/rubygems_ext.rb:45:in `gem_load'
Tasks: TOP => spec:deps
(See full trace by running task with --trace)
```

7646: Pin jruby-jars in warbler test r=deivid-rodriguez a=deivid-rodriguez



<!--
Thanks so much for the contribution!

If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.

To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->

### What was the end-user or developer problem that led to this PR?

<!-- Write a clear and complete description of the problem -->

The problem is that our CI is broken after the jruby-9.2.10.0 release.

### What is your fix for the problem, implemented in this PR?

My workaround is to pin the jruby-jars dependency of the warbler test to 9.2.9.0.

<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->

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

It no longer works with jruby-jars 9.2.10.0.

7635: Update code of conduct template to CC2.0 r=colby-swandale a=CoralineAda

### What was the end-user or developer problem that led to this PR?
The Contributor Covenant was updated to version 2.0 last year, but bundler was still using the old version.

### What is your fix for the problem, implemented in this PR?
I updated the `.md.tt` file containing the template, careful to preserve the interpolation of the email address.

Co-authored-by: Coraline Ada Ehmke <coraline@idolhands.com>