SOLR-18082: Add jersey BOM to align versions of all jersey dependencies

[malliaridis]

https://issues.apache.org/jira/browse/SOLR-18082

Description

jersey provides a bill of materials that can be used to align all jersey dependencies and manage their versions via the BOM. Right now the only dependency org.glassfish.jersey.containers:jersey-container-jetty-http is out-of-sync due to development history of the jersey modules.

Solution

This PR introduces the jersey BOM, adds it to the only module (:solr:core) that includes the jersey dependencies in the dependencies block and removes the existing versions of jersey to align them via the BOM.

Tests

No tests were added or altered.

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide
• I have added a changelog entry for my change

[epugh]

This all makes sense to me, but I don't have a great handle on how gradle dependencies get managed.

Looks like this would get us to "everything matching jersey 3.1.11"?

[epugh]

love the removal of a TODO!

[malliaridis]

Looks like this would get us to "everything matching jersey 3.1.11"?

@epugh Exactly. A bill of materials (BOM), if added correctly to a module (that is with that platform(...) notation) takes care of the modules it manages, specifically their versions. So the BOM of jersey that is added will manage all jersey dependencies added to the that module.

However, following this route makes it mandatory to always include the BOM together with the dependencies that do not define a version in the libs.version.toml and that are managed by the BOM, because otherwise they may not resolve correctly outside our project (specifically in Maven / pom.xml files).

I will check for any related jira issues to update the PR with a ticket number, and check the POM files to confirm it resolves everything correctly before merging it.