Add traceparent/traceId support for search

[sgup432]

Description

This change adds support for traceparent header which can be sent by the user, and thereby supporting traceId as well.
This change is specifically tested/written for a search request, and also adds trace-id support in search slow log as well.

Sample search slow log while the change was manually tested

[2025-10-28T03:57:33,764][TRACE][i.s.s.query              ] [runTask-0] [products][0] took[21.7ms], took_millis[21], total_hits[2 hits], stats[], search_type[QUERY_THEN_FETCH], total_shards[1], source[{"query":{"match":{"category":{"query":"electronics","operator":"OR","prefix_length":0,"max_expansions":50,"fuzzy_transpositions":true,"lenient":false,"zero_terms_query":"NONE","auto_generate_synonyms_phrase_query":true,"boost":1.0}}}}], id[], trace-id[4bf92f3577b34da6a3ce929d0e0e4736]

Related Issues

#18512

Check List

• Functionality includes testing.
• [] API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

❌ Gradle check result for 7dc64ff: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for c994206: null

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for 5f7eeb1: null

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[reta]

@sgup432 My apologies, but I don't understand what the problem this pull request solves

• the OpenSearch with OpenTelemetry plugin installed will automatically pick the trace from HTTP headers, we support all formats that OpenTelemetry provides [1]
• the tracing context is being passed from threat to thread using ThreadContext and ThreadContextBasedTracerContextStorage [2], that would use one of the default context propagator OpenTelementry provides [2]
• the tracing context is being injected into downstream HTTP calls using ThreadContext
• the tracing context is being injected into downstream transport calls using ThreadContext as well

There is no need to introduce any custom headers here - we purely rely on the telemetry provider (in this case, OpenTelementry) for end to end context propagation, that already works (at least it did), if not - we have to fix that. Please let me know if you have any further questions.

Thank you.

[1] https://opentelemetry.io/docs/specs/otel/context/api-propagators/#propagators-distribution
[2] https://github.com/opensearch-project/OpenSearch/blob/main/server/src/main/java/org/opensearch/telemetry/tracing/ThreadContextBasedTracerContextStorage.java