Jetty 12.0.x resource Servlet

[gregw]

Fix #10738
This is the start of a split of the DefaultServlet into a ResourceServlet.

[gregw]

This could be 12.0 ... or perhaps best to be 12.1

[gregw]

@lorban thoughts?

[lorban]

It's a good first step that IMHO could be merged in as-is, but it needs changes to the javadoc of ResourceServlet and probably some changes to the doc too.

[janbartel]

Seems like the DefaultServlet is now pretty much the same as the ResourceServlet? What are the actual differences?

[gregw]

Seems like the DefaultServlet is now pretty much the same as the ResourceServlet? What are the actual differences?

They are substantially similar, so the change is mostly in perception and future flexibility. But there are real changes in this PR:

• In ResourceServlet the String getEncodedPathInContext(HttpServletRequest req, String includedServletPath) method is replaced with String getEncodedPathInContext(HttpServletRequest request, boolean included). This is not only more efficient, but it allows the included path to be correctly calculated by the implementation.
• The actual implementation of String getEncodedPathInContext(HttpServletRequest request, boolean included) is more comprehensive and embraces the HttpServletMapping, rather than the half-way isDefaultMapping concept, to better determine the correct path in most circumstances
• The pathInfoOnly configuration is re-introduced as that can have meaning for non default mappings.
• The DefaultServlet now warns if it is mapped anywhere but the default pathspec. Once this has moved our users off using DefaultServlet, we can remove that check for a simpler/faster path calculation... or keep it to ensure that the actual default servlet has a specific sane configuration.
• The DefaultServlet can still be configured with context init parameters, whilst the ResourceServlet cannot.

[gregw]

@joakime @lorban I added back the DefaultServletTest as it was, then added a bunch of parameterized tests for ResourceServletTest

[gregw]

@lorban slight javadoc change, so please review.
@janbartel nudge.

[janbartel]

+1 subject to fixing the ci build failure.

[gregw]

I think the CI failures are flakes (we gotta get on top of that!)

[lorban]

Javadoc could be improved a bit, and we need to decide what to do about that jetty-asciidoctor-extensions module.

Otherwise LGTM.

[lorban]

There is also the jetty-asciidoctor-extensions module that's not activated and stuck at version 12.0.10-SNAPSHOT. Shouldn't it be enabled too?

[lorban]

Should the javadoc say something to users willing to configure a ResourceServlet instance at /? Should we warn when we detect that?

[gregw]

I'm not sure anything needs to be said. They can definitely deploy a ResourceServlet at '/' and it will work fine. They just miss out on any extras or efficiencies we may put into DefaultServlet.

[gregw]

@sbordet This PR is now also trying to undo the changes introduced in #11737 that meant we no longer compiled the code used in documentation. I think I've got it right now (the poms had already stagnated), but can you double check it please?