getHttpServletMapping for async dispatch

[gregw]

Unlike the path methods (contextPath, servletPath, pathInfo), the new 4.0 getHttpServletMapping() method does not change when an AsyncContext.dispatch() is done, making it more like include.

[gregw]

See jakartaee/servlet#309 for some clarification (hopefully?)

[gregw]

I think this is related to the work that I'm doing in #4777, where I've made HttpURI, HttpFields and MetaData immutable. When doing dispataches the entire fields and uri instances are replace and then reverted, rather than their component parts.

I think a similar approach can be taken with pathInContext, servletPath, pathInfo and pathMapping. Rather than handling each individually, I think the request can carry an immutable PathInfo object that would have those 4 fields. It would be set and replaced as a whole when the request is scoped to a servlet and when it is dispatched to another target. More over, in the cases of exact matches, the PathInfo instant can be the same for all requests (associated with the ServletMapping?). There can be special types of PathInfo implementations for some of the bizarre cases outline in jakartaee/servlet#309

[gregw]

@lachlan-roberts to get your brain into this space, can you write a little webapp that can be deployed on tomcat and undertow to verify if they follow the TCK with respect to [2] in jakartaee/servlet#309

[gregw]

Note also that the current implementation of AsyncContext.dispatch() handles the request attributes required by the spec in an entirely different way to the attributes for Dispatcher. Testing by @lorban has indicated that for a simple async request, the creation of the attribute map is a significant source of garbage. So are part of this issue, it might be good to look at fixing those attributes as well.