add request ID injection to context to enable tracking requests across services

[erlan-z]

What this PR does:
This PR adds support for injecting a request ID into the request context to enable tracking requests across services.

• If the configured request_id header is present and non-empty, its value is used as the request ID.
• Otherwise, a new UUID is generated.
• The request ID is stored in the context, accessible via requestutil.RequestIdFromContext(r.Context()).

This ID is propagated through the service call chain and enables future tracking of downstream operations tied to a single originating request.

Note: While there is no active usage of the request ID yet, the immediate goal is to use it for tracing storage-related resource usage, especially for identifying heavy or costly queries originating from a single logical request.

Which issue(s) this PR fixes:
Fixes #

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

Logs from testsing split queries got same request id

• query-frontend logs:

ts=2025-07-21T22:30:37.95781Z caller=handler.go:314 level=error org_id=fake msg="query request received in QFE handler" requestId=request-id-sharded

• querier logs:

ts=2025-07-21T22:30:37.958862Z caller=scheduler_processor.go:170 level=error org_id=fake msg="query request received in Querier" requestId=request-id-sharded
ts=2025-07-21T22:30:37.958876Z caller=scheduler_processor.go:170 level=error org_id=fake msg="query request received in Querier" requestId=request-id-sharded
ts=2025-07-21T22:30:37.958901Z caller=scheduler_processor.go:170 level=error org_id=fake msg="query request received in Querier" requestId=request-id-sharded

• ingester logs:

ts=2025-07-21T22:30:37.967425Z caller=ingester.go:2208 level=error msg="query request received in Ingester" requestId=request-id-sharded
ts=2025-07-21T22:30:37.967434Z caller=ingester.go:2208 level=error msg="query request received in Ingester" requestId=request-id-sharded
ts=2025-07-21T22:30:37.96775Z caller=ingester.go:2208 level=error msg="query request received in Ingester" requestId=request-id-sharded

• ruler logs:

ts=2025-07-22T00:51:39.887737Z caller=compat.go:191 level=error msg="query request id from ruler" requestId=d0437ed4-a924-48c6-bbee-eb9152bbbf5b

• ingester logs:

ts=2025-07-22T00:51:39.889274Z caller=ingester.go:2208 level=error msg="query request received in Ingester" requestId=d0437ed4-a924-48c6-bbee-eb9152bbbf5b

[justinjung04]

Nice!

[justinjung04]

What's the goal here? Do you imagine a downstream component changing the header?

[erlan-z]

No specific case—just a precaution to avoid changing the context if the value already exists. This shouldn't normally happen, but in case it does, it's safer not to override it.

[justinjung04]

Thx for the logs from testing!

[danielblando]

The code lgtm, but it feels we are rewriting code from the log headers. The logs header is specific for logging, but one of the key parts was transferring ctx between services which seems to be duplicating here. I think we can reuse at least that logic

What if, we have a new config for the requestId header, but use the same middleware but adding the new header as targetHeader?
we can also refactor that util_log context function to a generic util.
would that also work? seems we would avoid some of this new changes

[danielblando]

nit: s/reqeusts/requests