feat: add reusable OpenTelemetry tracing module

[delthas]

What

Extracts the OpenTelemetry tracing code duplicated across backbeat, cloudserver and vault into a single shared module, lib/tracing/, consumed via require('arsenal/build/lib/tracing').

It provides:

• init(options) / close() / isEnabled() — SDK bootstrap (ParentBased(TraceIdRatio) sampler, span limits, traces-only, fail-fast asserts, bounded-flush shutdown race). Config assembly is split into a testable buildSdkConfig().
• loadTrustedHosts() / makeTrustedHostsHook() — outbound trust boundary that strips traceparent/tracestate on calls to untrusted hosts. OTEL_TRUSTED_HOSTS supports NO_PROXY-style .suffix entries (e.g. .svc.cluster.local trusts every in-cluster service, subdomains and apex). We do not bother doing a trim() on each host, the value is expected to be well-formed, avoiding swallowing formatting mistakes.
• isHealthPath(url, pathSet) — probe/scrape span filter.
• instrumentApiMethod(handler, name) — per-API-method span wrapper (scope scality.api, span api.<method>, error.type attribute; service disambiguated by service.name on the resource).
• kafka.* — W3C trace-context propagation over node-rdkafka headers.

Design notes

• Consumers own their instrumentations. init() takes a lazy instrumentations: () => Instrumentation[] thunk, invoked only when OTEL is enabled. So arsenal carries no instrumentation-* packages — only the OTEL SDK core, as optionalDependencies; @opentelemetry/api stays a hard (inert) dependency.
• Deep-require, not require('arsenal').tracing. The arsenal barrel eagerly loads ioredis/mongodb; reaching init() through it would load them before OTEL can patch them. The lib/tracing subpath loads nothing instrumentable at import time.
• Off by default (ENABLE_OTEL=true to enable); see lib/tracing/README.md for env vars and usage.

Consumer adoption (backbeat, cloudserver, vault) lands in separate PRs once this ships.

Issue: ARSN-586

[bert-e]

Hello delthas,

My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.

Available options

name	description	privileged	authored
/after_pull_request	Wait for the given pull request id to be merged before continuing with the current one.
/bypass_author_approval	Bypass the pull request author's approval	⭐
/bypass_build_status	Bypass the build and test status	⭐
/bypass_commit_size	Bypass the check on the size of the changeset TBA	⭐
/bypass_incompatible_branch	Bypass the check on the source branch prefix	⭐
/bypass_jira_check	Bypass the Jira issue check	⭐
/bypass_peer_approval	Bypass the pull request peers' approval	⭐
/bypass_leader_approval	Bypass the pull request leaders' approval	⭐
/approve	Instruct Bert-E that the author has approved the pull request.		✍️
/create_pull_requests	Allow the creation of integration pull requests.
/create_integration_branches	Allow the creation of integration branches.
/no_octopus	Prevent Wall-E from doing any octopus merge and use multiple consecutive merge instead
/unanimity	Change review acceptance criteria from one reviewer at least to all reviewers
/wait	Instruct Bert-E not to run until further notice.

Available commands

name	description	privileged
/help	Print Bert-E's manual in the pull request.
/status	Print Bert-E's current status in the pull request TBA
/clear	Remove all comments from Bert-E from the history TBA
/retry	Re-start a fresh build TBA
/build	Re-start a fresh build TBA
/force_reset	Delete integration branches & pull requests, and restart merge process from the beginning.
/reset	Try to remove integration branches unless there are commits on them which do not appear on the source branch.

Status report is not available.

[bert-e]

Waiting for approval

The following approvals are needed before I can proceed with the merge:

• the author

• 2 peers

[codecov]

Codecov Report

❌ Patch coverage is 94.84979% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.92%. Comparing base (a1fa5b4) to head (5944736).

Files with missing lines	Patch %	Lines
lib/tracing/index.ts	0.00%	7 Missing ⚠️
lib/tracing/bootstrap.ts	96.29%	2 Missing ⚠️
lib/tracing/instrumentation.ts	96.96%	2 Missing ⚠️
lib/tracing/kafkaTraceContext.ts	98.21%	1 Missing ⚠️

Additional details and impacted files

@@                 Coverage Diff                 @@
##           development/8.4    #2632      +/-   ##
===================================================
+ Coverage            73.65%   73.92%   +0.26%     
===================================================
  Files                  223      229       +6     
  Lines                18247    18480     +233     
  Branches              3776     3847      +71     
===================================================
+ Hits                 13440    13661     +221     
- Misses                4802     4814      +12     
  Partials                 5        5              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[delthas]

@francoisferrand @DarkIsDude intentionally tagging you here as this is moving cloudserver code you already reviewed into this PR.

[DarkIsDude]

LGTM

[bert-e]

Waiting for approval

The following approvals are needed before I can proceed with the merge:

• the author

• 2 peers

[claude]

• instrumentCallbackHandler (lib/tracing/instrumentation.ts:49-73) has a double-end-span path: if the original callback throws after the wrappedCallback has already called endSpan, the catch block calls endSpan again on the finished span. Harmless at runtime (OTEL no-ops it) but generates diagnostic noise and obscures the real error source. Guard with a spanEnded flag.

Review by Claude Code

[delthas]

/approve

[bert-e]

I have successfully merged the changeset of this pull request
into targetted development branches:

• ✔️ development/8.4

The following branches have NOT changed:

• development/6.4
• development/7.10
• development/7.4
• development/7.70
• development/8.1
• development/8.2
• development/8.3

This pull request did not target the following hotfix branch(es) so they
were left untouched:

• hotfix/7.10.46
• hotfix/7.10.0
• hotfix/7.70.4
• hotfix/7.4.9
• hotfix/7.10.3
• hotfix/7.4.2
• hotfix/7.10.57
• hotfix/7.70.25
• hotfix/7.10.47
• hotfix/7.10.1
• hotfix/7.4.7
• hotfix/6.4.7
• hotfix/7.4.5
• hotfix/7.7.0
• hotfix/7.8.0
• hotfix/7.9.0
• hotfix/7.5.0
• hotfix/7.4.3
• hotfix/7.4.4
• hotfix/7.10.2
• hotfix/7.10.31
• hotfix/7.4.8
• hotfix/7.6.0
• hotfix/7.70.14
• hotfix/7.4.0
• hotfix/7.10.29
• hotfix/7.10.43
• hotfix/7.10.4
• hotfix/7.4.10
• hotfix/7.4.1
• hotfix/7.70.20
• hotfix/7.2.0
• hotfix/7.10.36
• hotfix/7.4.6

Please check the status of the associated issue ARSN-586.

Goodbye delthas.

The following options are set: approve