[extension/headers_setter] Add headers_setter extension.

[kovrus]

Description:

Resolves #12922

The headers_setter extension implements ClientAuthenticator
and is used to set request headers in gRPC / HTTP exporters with values provided
via the extension configuration or request metadata (context).

Use cases include but are not limited to enabling multi-tenancy for observability
backends such as Tempo, Mimir, Loki and others by setting the X-Scope-OrgID
header to the value extracted from the context.

Link to tracking Issue:
This change potentially can address the following issues related to multi-tenancy use cases:

• OTEL Exporter - multi-tenancy support based on labels opentelemetry-collector#5733

• [prometheusremotewriteexporter] multi-tenancy support based on labels #7945

• Auth-context available for use in export-config opentelemetry-collector#4814

• Access headers in OTLP exporter opentelemetry-collector#5264

• We can drop specific multi-tenant implementation in Loki exporter/loki: handle multi-tenant use-cases #12415

Open discussion:

• At the moment, this extension cannot be used with the batch processor, see Change batch processor to take client info into consideration opentelemetry-collector#4544
• The extension is implemented as the client type authenticator, so it uses auth and authenticator config to be enabled which might be confusing. One option could be renaming auth -> interception and authenticator -> interceptor cc: @jpkrohling

...
exporters:
...
  loki:
    ...
    auth:
      authenticator: headers_setter  
...

Alternatives:
It is also possible to implement the same functionality (setting header values from context) in opentelemetry-collector by implementing a round tripper and interceptor that will set in confighttp.go and configgrpc.go and changing the headers configuration of HTTP / gRPC client settings. This approach seems to be more complex and might impact some exporters in pentelemetry-collector-contrib

Testing:

• Unit tests
• Locally with the following Otel collector config:

extensions:
  headers_setter:
    headers:
      key: X-Scope-OrgID
      from_context: "tenant"

receivers:
  otlp/1:
    protocols:
      grpc:
        include_metadata: true
        endpoint: localhost:4000
  otlp/2:
    protocols:
      grpc:
        endpoint: localhost:4318
        include_metadata: true

exporters:
  otlp:
    endpoint: localhost:4318
    tls:
      insecure: true
      insecure_skip_verify: true
    headers:
      tenant: "value1"
  logging:

  loki:
    labels:
      resource:
        container_name: ""
        container_id: ""
    endpoint: https://localhost:3100/loki/api/v1/push
    auth:
      authenticator: headers_setter

service:
  extensions: [headers_setter]
  pipelines:
    logs/1:
      receivers: [otlp/1]
      exporters: [otlp]
    logs/2:
      receivers: [otlp/2]
      exporters: [loki]

Documentation:
See README.md in the new headers_setter extension.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: kovrus / name: Ruslan Kovalov (e01947098cbb0140bcfd437e2a1a71f3ef7f184c)

[jpkrohling]

@kovrus, please open an issue proposing this new component (see the contributing guidelines). I'm willing to sponsor this one.

[jpkrohling]

Looks almost perfect, thanks!

[jpkrohling]

If FromContext is empty, what would happen?

[jpkrohling]

I guess this answers the question I had earlier about empty FromContext values.

[kovrus]

The semantic is following:

from_context: "key" -> if key is missing from context then header value set to ""
from_context: "key" -> if key from context is "" then header value set to ""
value: "" -> header value set to ""

I was thinking of not setting headers at all if their value is "" but then decided to make it arguably more explicit. Also, "" is a valid header value.

[jpkrohling]

LGTM, just double-check the go version we are using in other modules, which might have been changed since this PR was opened.