Optimize `Scannable#name()` and related logic

[Stephan202]

Performance is improved in two ways:

• By invoking Scannable#stepName() only when Attr.NAME is not explicitly set.
• By optimizing Traces#extractOperatorAssemblyInformationParts, to which several Scannable#stepName() implementations delegate.

The Scannable#name() logic may be executed many times, e.g. if a hot code path uses {Mono,Flux}#log or Micrometer instrumentation. The added benchmark shows that for large stack traces, the new Traces implementation is several orders of magnitude more efficient in terms of compute and memory resource utilization.

Deferral of invocation of Scannable#stepName() assumes that said method does not have side-effects. This is true for all built-in implementations.

While there, improve two existing benchmarks by utilizing the black hole to which benchmark method return values are implicitly sent.

[quarkus-bot[bot]]

/cc @zakkak (native-image)

[gsmet]

This is very interesting and thanks for opening this issue as we had a lot of issues with Jansi - especially with dev mode class loaders.

If it works, I think I would even be convinced that we try to enable it by default with Java 21 if doable and sufficiently stable.

[geoand]

If it works, I think I would even be convinced that we try to enable it by default with Java 21 if doable and sufficiently stable.

Yeah, when we move to a JDK 21 baseline, it would be nice to have a look and see if we can depend on this