[chore][cmd/mdatagen] Use metadata.yaml as a schema source for references

[jkoronaAtCisco]

Description

Previously, the schemagen loader used config.schema.yaml as the standalone file format for schema references. This PR changes the source of truth for cross-component schema references to metadata.yaml — the same file that already exists in every component directory.

Instead of parsing a bare ConfigMetadata JSON-schema object, the loader now reads the config: section from a component's metadata.yaml, matching the structure that mdatagen already generates for every component. The generated output is likewise renamed to metadata.yaml (placed under internal/metadata/) and wrapped with the standard metadata.yaml envelope (type, status, config), so it is usable as a reference target by other components in the same way.

Link to tracking issue

Fixes #15259

Testing

Existing unit tests in internal/schemagen and cmd/mdatagen/internal were updated to reflect the new file name and Metadata wrapper format. The persistToFile test was strengthened to verify a full round-trip through loadFromFile. All tests pass.

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

✅ 7 untouched benchmarks
⏩ 76 skipped benchmarks¹

---

_{Comparing jkoronaAtCisco:mdatagen_external_configs (9341273) with main (e9f60fc)}

Footnotes

1. 76 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[codecov]

Codecov Report

❌ Patch coverage is 94.11765% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.24%. Comparing base (0afcdf0) to head (9341273).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...datagen/internal/samplescraper/generated_config.go	0.00%	1 Missing and 1 partial ⚠️

❌ Your patch check has failed because the patch coverage (94.11%) is below the target coverage (95.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #15272      +/-   ##
==========================================
+ Coverage   91.23%   91.24%   +0.01%     
==========================================
  Files         704      704              
  Lines       45926    45948      +22     
==========================================
+ Hits        41899    41926      +27     
+ Misses       2822     2819       -3     
+ Partials     1205     1203       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dmitryax]

Why do we need all this extra yaml? Why cant we generate the exact schema that goes under metrics_config in json format?

[jkoronaAtCisco]

That was leftover from my previous attempt to fix this, now as it's no longer needed I cleaned up the template. However I'd like to keep it in yaml as it's better to have it consistent with mdatagen-specific data model for code and docs generation.

[dmitryax]

However I'd like to keep it in yaml as it's better to have it consistent with mdatagen-specific data model for code and docs generation

But we need to generate json.schema not ConfigMetadata. We are fortunate they are the same for now, but it's not going to be the case going forward. I don't think we should use it

[jkoronaAtCisco]

ConfigMetadata becomes underlying model - the source for json schema, go code and docs. MetricsBuilderConfig becomes part of the config which is relevant for go code and docs as well as for json schema. So that's why I'd like to keep it consistent. At the end I won't output ConfigMetadata anywhere. It's just a working model.

[dmitryax]

ConfigMetadata becomes underlying model

Why? Do you want to remove https://github.com/open-telemetry/opentelemetry-collector/blob/main/cmd/mdatagen/internal/templates/config.go.tmpl as the next step? My concern is that generating metadata.yaml from metadata.yaml might be confusing and error prone

[dmitryax]

I'm merging this PR for now. But we need to address this going forward one way or another