feat: add support for HTTP Headers instrumentation rule in UI backend (+ add docs)

[BenElferink]

Following up after: #2826

---

This PR adds API support for the new HTTP Headers rule.
This PR also adds the rule to Odigos Docs.

The UI itself still needs an update via the UI-Kit: https://github.com/odigos-io/ui-kit/pull/134

[Copilot]

Pull Request Overview

This PR extends the UI backend to support a new HTTP Headers instrumentation rule and adds corresponding documentation.

• Introduce HeadersCollection in service layer conversions and input builders
• Extend GraphQL schema, models, and resolvers to expose headersCollection
• Add “Headers Collection” docs and update navigation order in docs

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
frontend/services/instrumentationrule.go	Added getHeadersCollectionInput, convertHeadersCollection, and wired headersCollection into rule DTOs
frontend/graph/schema.graphqls	Defined HeadersCollection/HeadersCollectionInput, updated InstrumentationRule and its input
frontend/graph/model/models_gen.go	Added HeadersCollection types and updated InstrumentationRule struct fields and enum constants
frontend/graph/generated.go	Extended execution functions to marshal/unmarshal headersCollection and updated resolver switch cases
docs/pipeline/rules/introduction.mdx	Inserted link to the new Headers Collection page
docs/pipeline/rules/headerscollection.mdx	New doc page for the Headers Collection rule
docs/mint.json	Updated sidebar order to include Headers Collection

Comments suppressed due to low confidence (2)

frontend/services/instrumentationrule.go:11

• The new headersCollection field isn’t evaluated here, so header‐only rules will fall back to UnknownType. Extend this function to check rule.HeadersCollection and return InstrumentationRuleTypeHeadersCollection when appropriate.

func deriveTypeFromRule(rule *model.InstrumentationRule)

frontend/services/instrumentationrule.go:122

• There is no existing unit test for getHeadersCollectionInput. Adding tests for various HeadersCollectionInput cases (nil, empty slice, populated slice) will prevent regressions.

func getHeadersCollectionInput(input model.InstrumentationRuleInput) *instrumentationrules.HttpHeadersCollection {

[blumamir]

LGTM.

Added few suggestion to the docs which can be nice to add (but optional)

[blumamir]

I think it can be valuable to also describe how this key is collected.

e.g. that an header key "foo" with value "bar" will be collected as span attribute named http.request.header.foo with attribute value ["bar"] (or http.response.header.foo if this is for response)

@edeNFed just making sure java is implemented this way (semconv)

[blumamir]

for http we have both client/server, and request/response.

I guess this configuration option will apply to all of them? might be worth mentioning here