Reduce tracing overhead

[schlosna]

Before this PR

For services with very high concurrency and request volumes (e.g. timelock), there is unnecessary overhead and contention in Tracer::logClearingTrace() determining whether debug logging is enabled. This Tracer::clearCurrentTrace() debug logging has outlived its useful life.

Builds on #1412

Benchmark                             (observability)  Mode  Cnt      Score      Error  Units
TracingBenchmark.nestedSpans            DO_NOT_SAMPLE  avgt   10    494.292 ±   43.218  ns/op
TracingBenchmark.nestedSpans                UNDECIDED  avgt   10    748.402 ±   36.206  ns/op
TracingBenchmark.nestedSpans                   SAMPLE  avgt   10  30336.603 ± 5844.814  ns/op
TracingBenchmark.traceWithSingleSpan    DO_NOT_SAMPLE  avgt   10    121.955 ±   18.840  ns/op
TracingBenchmark.traceWithSingleSpan        UNDECIDED  avgt   10    124.761 ±   18.362  ns/op
TracingBenchmark.traceWithSingleSpan           SAMPLE  avgt   10    368.724 ±   76.932  ns/op

After this PR

Benchmark                             (observability)  Mode  Cnt      Score      Error  Units
TracingBenchmark.nestedSpans            DO_NOT_SAMPLE  avgt   10    486.959 ±    3.825  ns/op
TracingBenchmark.nestedSpans                UNDECIDED  avgt   10    741.624 ±   50.668  ns/op
TracingBenchmark.nestedSpans                   SAMPLE  avgt   10  30965.189 ± 1968.021  ns/op
TracingBenchmark.traceWithSingleSpan    DO_NOT_SAMPLE  avgt   10     54.028 ±    4.108  ns/op
TracingBenchmark.traceWithSingleSpan        UNDECIDED  avgt   10    104.858 ±    3.227  ns/op
TracingBenchmark.traceWithSingleSpan           SAMPLE  avgt   10    395.974 ±    9.767  ns/op

==COMMIT_MSG==
Remove unnecessary debug logging
==COMMIT_MSG==

Possible downsides?

[changelog-app]

Generate changelog in changelog/@unreleased

What do the change types mean?

• feature: A new feature of the service.
• improvement: An incremental improvement in the functionality or operation of the service.
• fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
• break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
  and external consumers of the service's API (e.g. customer-written software or integrations).
• deprecation: Advertises the intention to remove service functionality without any change to the
  operation of the service itself.
• manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
  performing database surgery, ...) at the time of upgrade for it to succeed.
• migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?

• ❗The break and manual task changelog types will result in a major release!
• 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
• ✨ All others will result in a minor version release.

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

Remove unnecessary debug logging

Check the box to generate changelog(s)

• Generate changelog entry

[autorelease3]

Released 6.24.0