[k176] Propagate trace ID with HTTP gRPC request.

[grafanabot]

Backport 8d34f85 from #11251

---

What this PR does / why we need it:
The changes in #10688 did not propage the trace ID from the context. Frontend.RoundTripGRPC would inject the trace ID into the request. That's not done in Frontend.Do. This changes extends the codec.EncodeRequest to inject the trace ID there. This is more inline with other metadata.

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• CHANGELOG.md updated
  • If the change is worth mentioning in the release notes, add add-to-release-notes label
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• For Helm chart changes bump the Helm chart version in production/helm/loki/Chart.yaml and update production/helm/loki/CHANGELOG.md and production/helm/loki/README.md. Example PR
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[trevorwhitney]

lgtm

[github-actions]

Trivy scan found the following vulnerabilities:

• HIGH openssl: Incorrect cipher key and IV length processing in libcrypto3 v3.1.2-r0. Fixed in v3.1.4-r0
• HIGH openssl: Generating excessively long X9.42 DH keys or checking excessively long X9.42 DH keys or parameters may be very slow in libcrypto3 v3.1.2-r0. Fixed in v3.1.4-r1
• HIGH openssl: Incorrect cipher key and IV length processing in libssl3 v3.1.2-r0. Fixed in v3.1.4-r0
• HIGH openssl: Generating excessively long X9.42 DH keys or checking excessively long X9.42 DH keys or parameters may be very slow in libssl3 v3.1.2-r0. Fixed in v3.1.4-r1