[improve][build] Upgrade Jakarta and servlet APIs within the Jakarta EE 10 level - #26354

Motivation

Several Jakarta API artifacts have newer patch releases within the Jakarta EE 10 level Pulsar
targets. Separately, javax.servlet-api was pinned at Servlet 3.1 while the Jetty ee8 environment
that consumes it actually implements Servlet 4.0.

Modifications

gradle/libs.versions.toml:

Plus the corresponding jar names in the server and shell distribution LICENSE.bin.txt files, and an
updated comment in the catalog explaining the servlet level pairing.

Each API is kept at the level its Jetty 12.1 environment actually implements. Checking the Jetty
12.1.12 POMs directly:

• org.eclipse.jetty.ee10:jetty-ee10 declares ee10.jakarta.xml.bind.api.version = 4.0.5 — exactly
  what this PR moves to;
• org.eclipse.jetty.ee8:jetty-ee8 declares ee8.jetty.servlet.api.version = 4.0.9
  (org.eclipse.jetty.toolchain:jetty-servlet-api), i.e. the ee8 environment implements Servlet 4.0,
  not the Servlet 3.1 previously pinned.

Please note: javax.servlet-api widens a public plugin surface

javax.servlet-api is what the PIP-472 AdditionalServlet plugin SPI compiles against. Raising it
from 3.1 to 4.0 widens that public plugin API surface. Plugins already compiled against Servlet 3.1
continue to work, since Servlet 4.0 is backward compatible; what changes is that new plugins may
start relying on Servlet 4.0 API. Flagging it explicitly because it is effectively a one-way door.

Deliberately not upgraded

These would move Pulsar past Jakarta EE 10 and out of step with the Jetty ee10 environment, so they
are left alone:

Note that jakarta.validation-api is not declared directly by any Pulsar module, but the version
catalog drives the pulsar-dependencies enforced platform, so a bump there would still pin Bean
Validation 3.1 globally for the swagger and Jersey transitives.

Verifying this change

• Make sure that the change passes the CI checks.

This change is a trivial rework / code cleanup without any test coverage.

Verified locally with ./gradlew sanityCheck and ./gradlew checkBinaryLicense.

Does this pull request potentially affect one of the following parts:

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

The public API impact is the AdditionalServlet plugin SPI moving from Servlet 3.1 to Servlet 4.0,
described above.