Upgrade from Guice 5.1.0 to 6.0.0

[NotMyFault]

Guice 6 smooths the way for Jakarta bindings, by keeping compatibility with javax.* and adding support for jakarta.* alongside, where Guice 7 ended support for javax.* bindings while supporting jakarta.* only.
Going from 5 to 6, over 5 to 7, is the safer approach because we can adapt jakarta when we're ready for it, without immediately cutting support for javax.

Additionally, it supports Java 21, which I'm really looking forward to :)

Closes #7987

Testing done

Compiling Jenkins against guice 6, while inspecting our methods bound properly.
Built a couple of pipeline and freestyle jobs and clicked around UI elements.
CI tests are passing too.

Proposed changelog entries

• Upgrade from Guice 5 to 6.

Proposed upgrade guidelines

N/A

Submitter checklist

• The Jira issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples).
  • Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[timja]

Might be worth a changelog entry?

[NotMyFault]

Might be worth a changelog entry?

There we go.

[MarkEWaite]

I've submitted a draft plugin bill of materials pull request to test this change.

Should it also be run in the acceptance tests?

[NotMyFault]

Should it also be run in the acceptance tests?

ATH is green.

[MarkEWaite]

ATH is green.

I think that we should check it with a full run of the acceptance test harness. I've submitted jenkinsci/acceptance-test-harness#1176 as a draft pull request.

My mistake. This was already tested successfully in ATH with jenkinsci/acceptance-test-harness#1173

[MarkEWaite]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback.

[basil]

#7477 seems to be holding up nicely.