Move to Jakarta based application servers

[tmortagne]

See xwiki/xwiki-rendering#318 for the rendering side of things.
See xwiki/xwiki-platform#3388 for the platform side of things.

Jira URLs

• XCOMMONS-2108: Upgrade to Bean Validation 3.0.2
• XCOMMONS-2109: Upgrade to Hibernate Validator 8.0.1
• XCOMMONS-2475: Use Expressly instead of Apache EL
• XCOMMONS-2777: Support both javax.inject and jakarta.inject annotations
• XCOMMONS-2797: Allow accessing a javax.inject.Provider as a jakarta.inject.Provider and the opposite
• XCOMMONS-2962: Provide a javax/jakarta bridge for Servlet APIs
• XCOMMONS-2963: Upgrade to Servlet 5.0
• XCOMMONS-2994: Upgrade to Websocket 2.1.1
• XWIKI-13963: Stop relying on the application server by default to resolve relative redirect URLs
• XWIKI-22586: Check all redirect URLs
• XWIKI-21137: Impossible to install XWiki Debian tomcat packages on Debian 12+ and Ubuntu 24.04+

Changes

Description

The idea is to do just enough for XWiki to work in jakarta based Application servers (Jetty 11+, Tomcat 10+).

Important

This PR might look like a big change already but it's actually very far from a 100% jakarta XWiki. What was done is really just the strict minimum to work in a jakarta application server and there will still be a lot of work after that to fully migrate to jakarta.
See https://design.xwiki.org/xwiki/bin/view/Proposal/Jakartamigration for more details.

Jakarta WebSocket 2.1.1

XWiki has been migrated to WebSocket 2.1.1 without any kind of bridge, so every WebSocket related APIs are broken. There was no obvious way to keep supporting WebSocket 1 but fortunately no use of those APIs were found in contrib extensions.

Jakarta Validation 3.0.2

XWiki has been migrated to Validation 3.0.2 (and Hibernate Validator 8.0.1) without any kind of bridge. A Javax Validation API JAR remain in the XWiki WAR because it's referenced by Jersey, but XWiki itself only support Jakarta Validation. In practice, it just means that Javax Validation annotations used in a contrib extension are going to be ignored. It's easy for an extension to support both Javax and Jakarta XWiki versions by declaring both Java Javax and Jakarta Validation annotations.

Jakarta Servlet 5.0

Migration to jakarta

• A javax.servlet <-> jakarta.servlet has been introduced.
• No Servlet related API should be broken.
• Except that the Filter and Servlet implementations declared in web.xml have all been moved to jakarta without keeping a javax compatible version. The reason is that there is no point keeping supporting those if XWiki is only used in jakarta based application servers, keeping the same class name also reduce the number of changes in the web.xml (in a sense, breaking them improve retro compatibility).
• All the oldcore servlet related APIs are now deprecated
  • The most commons Servlet related API has been added to the Container API to reduce the need to directly access it
  • A new script oriented Container API has been introduced
• Move to XJetty to Jetty 12 EE10 (instead of EE8)
• When XWiki is running in Jetty 12 EE10 (not just XJetty, standard Jetty too), allow “ambiguous” URIs in getServletPath and getPathInfo
• New Tomcat 10 based Debian packages

Behavior changes

• Redirect URLs are now checked in all contexts (injected by a servlet filter for all requests)
• By default, relative redirect URLs are now resolved by XWiki instead of the application server (reduce setups requirement)

Jakarta Inject 2.0.1

It was probably not strictly required, but both javax and jakarta Inject APIs are now supported at the same time.

TODO

• make Sonar happy with the new rules
• realtime UI test seems to be broken, probably some mistake was made when moving to WebSocket 2.1.1
• still a few others UI tests failing in the regular build
• find how to support special escaped characters in Tomcat 10+ (stuff like ALLOW_ENCODED_SLASH and ALLOW_BACKSLASH system properties have been removed and replaced by properties in the <Connector element in server.xml)
• run/fix Environment Tests
• would be good to optimize a bit more the size of the xjetty package (i.e. add some more JAR exclusions)

Executed Tests

Not much new tests, but every single UI test and a lot of unit tests are impacted by this change so just the fact that they are passing is a good test.

Expected merging strategy

• Prefers squash: Yes