Refactor to common HTTP transaction naming strategy

[SylvainJuge]

Problem description

Issue discovered while trying to add support for a new high-level HTTP framework (Spring Webflux).

We have a few different strategies when naming HTTP transactions:

• Servlet (low-level, uses what is available at HTTP level), two configuration options:

  • use_path_as_transaction_name : might create high-cardinality for transaction names
  • url_groups: allows to restrict issues with use_path_as_transaction_name
  • needs to deal with JSPs

• JAX-RS (high-level framework)

  • by default naming is defined with ClassName#methodName of the matched resource method
  • use_jaxrs_path_as_transaction_name allows to reuse path template GET /item/{id} instead

• Spring MVC (high-level framework)

  • by default naming is defined with ClassName#methodName of the matched controller method
  • no option to use any request pattern (which is likely to be made available by Spring MVC as a request attribute).

• Spring Webflux (high-level framework)

  • Similar to Spring-MVC, not yet merged (see add Spring Webflux server support #1305).

Common

• name should be set to GET unknown route when the transaction name is not known.

Proposal

• provide a common configuration option similar to use_jaxrs_path_as_transaction_name but not framework-specific
• avoid duplication for every framework
• provide fallback to what is available to prevent unnamed transactions
• optional: allow to re-use low-level naming strategies for non-Servlet frameworks (Jetty, Netty HTTP, ...).
• optional: avoid common causes of high-cardinality by ignoring use_path_as_transaction_name for 404 (actual value is still available in request.url.full if required for investigation.