Rework WebMvcMetricsFilter to be general purpose with tech strategies

[philwebb]

The WebMvcMetricsFilter is currently tied to Spring MVC but we'd also like to support Jersey and possibly general servlets. We could rework WebMvcMetricsFilter to MetricsFilter that provides the general code and create new technology specific strategies that can extract tags based on a specific technology.

[haykart]

Dear Spring boot developers, I have a small question regarding WebMvcMetricsFilter: Did you planned to include the fix from #16014 PR to the 2.2.0.RELEASE?

[wilkinsona]

@haykart please don't ask questions on unrelated issues. For the record, the changes proposed in #16104 are already in 2.2.0 snapshots and will, therefore, be included in 2.2.0.RELEASE.

[jkuipers]

I also noted that when no MVC path mapping can be resolved, the request's pathInfo is used in the current implementation (org.springframework.boot.actuate.metrics.web.servlet.WebMvcTags#getPathInfo).
What that means is that if e.g. a Spring Security filter prevents a request from reaching the DispatcherServlet, which is mapped as the default servlet in a default Boot app, the pathInfo is always null so the uri will always be reported as "root". The actual path is contained in the request's servletPath in this set-up, never in the pathInfo. I was surprised by this when our metrics suggested that requests were being made to the root of our app, even though these were actually to a different URL that would normally be handled by a Spring-MVC controller but were handled by a Spring Security filter instead in this case.

Maybe you could consider changing this if the support is being reworked anyway so that the uri reported matches the actual path.