## Description

Add a new `config_data` dimension source for OTel custom API metrics,
letting users pull values from an API definition's `config_data` map
into metric labels. This enables per-API tagging (e.g. environment,
team, cost-centre) without requiring custom headers or middleware. The
gateway only copies `config_data` into the request context when at least
one instrument uses the `config_data` source, the API has
`config_data_disabled: false`, and the map is non-empty. When the key is
missing from the map (or the API has no config_data), the configured
`default` value is used.

### Configuration example

```json
{
  "name": "custom.configdata.requests.total",
  "type": "counter",
  "description": "Counter with config_data dimensions",
  "dimensions": [
    { "source": "metadata",     "key": "method",      "label": "http.request.method" },
    { "source": "metadata",     "key": "api_id",      "label": "tyk.api.id" },
    { "source": "config_data",  "key": "environment",  "label": "configdata.environment", "default": "" },
    { "source": "config_data",  "key": "team",         "label": "configdata.team",        "default": "" }
  ]
}
```

## Related Issue

TT-16884

## Motivation and Context

Users need to slice OTel metrics by business-level attributes (team,
environment, service tier) that live in `config_data`. Before this
change the only way to get these labels was to inject custom headers
upstream. Adding `config_data` as a first-class dimension source removes
that workaround and keeps cardinality under the user's control via the
existing custom metrics configuration.

## How This Has Been Tested

- **Unit tests** — `dimension_test.go`: extractor returns config_data
values, falls back to `""` when map is nil or key is missing.
`registry_test.go`: `NeedsConfigData()` flag set correctly.
`validation_test.go`: `config_data` accepted as valid source.
`metrics_instrument_test.go`: `NeedsConfigData()` delegation.
- **E2E tests** (custom profile) — three new test cases in
`metrics_test.go`:
- `configdata dimension populates from API config_data` — sends traffic
to an API with `config_data:
{"environment":"staging","team":"platform"}` and asserts both labels
appear in Prometheus.
- `configdata dimension has all expected labels` — verifies the full
label set on the metric.
- `configdata dimension uses default for API without config_data` —
sends traffic to an API with no config_data and asserts the default
empty-string label.
- **Full profile matrix** — `default` and `custom` profiles pass;
remaining profiles (`disabled`, `cardinality`, `response-headers`,
`mcp`) unaffected.

## Screenshots (if appropriate)

## Types of changes

<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Refactoring or add test (improvements in base code or adds test
coverage to functionality)

## Checklist

<!-- Go over all the following points, and put an `x` in all the boxes
that apply -->
<!-- If there are no documentation updates required, mark the item as
checked. -->
<!-- Raise up any additional concerns not covered by the checklist. -->

- [ ] I ensured that the documentation is up to date
- [ ] I explained why this PR updates go.mod in detail with reasoning
why it's required
- [ ] I would like a code coverage CI quality gate exception and have
explained why




<!---TykTechnologies/jira-linter starts here-->

### Ticket Details

<details>
<summary>
<a href="https://tyktech.atlassian.net/browse/TT-16884" title="TT-16884"
target="_blank">TT-16884</a>
</summary>

|         |    |
|---------|----|
| Status  | Open |
| Summary | OTel metrics ConfigData dimension source |

Generated at: 2026-03-20 16:55:57

</details>

<!---TykTechnologies/jira-linter ends here-->