[mdatagen] Add deprecation date and migration note fields for deprecated components

[ChrsMark]

Description

This PR adds deprecation date and migration note fields for deprecated components as described at #12359.

Example metadata file:

status:
  class: receiver
  stability:
    development: [logs]
    beta: [traces]
    stable: [metrics]
    deprecated: [profiles]
  deprecation:
    profiles:
      migration: "no migration needed"
      date: "2025-02-05"

Example README.md:

Status
Stability	deprecated: profiles
	development: logs
	beta: traces
	stable: metrics
Deprecation of profiles	Date: 2025-02-05
	Migration Note: no migration needed

I'd appreciate any suggestions if there is a better way to represent this information in the markdown table.

Link to tracking issue

Fixes #12359

Testing

Added

Documentation

Added

/cc @atoulme who filed the feature request issue originally.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.20%. Comparing base (909a8bb) to head (27cb311).
Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #12464   +/-   ##
=======================================
  Coverage   92.19%   92.20%           
=======================================
  Files         469      469           
  Lines       25327    25351   +24     
=======================================
+ Hits        23351    23375   +24     
  Misses       1568     1568           
  Partials      408      408           

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

[atoulme]

this PR covers well what I was asking for. LGTM

[atoulme]

I recommend we start adopting the additional yaml in contrib and make contrib tests pass, then merge this PR. We can do that with one PR per deprecated component:

• cmd/githubgen
• exporter/lokiexporter
• exporter/opencensusexporter
• exporter/sapmexporter
• processor/routingprocessor
• receiver/opencensusreceiver
• receiver/sapmreceiver

[ChrsMark]

Does this mean we should create and merge PRs like open-telemetry/opentelemetry-collector-contrib#38144? My concern is that contrib CI will be broken in that case but it looks like chicken-egg problem 🤔 .

[atoulme]

#12484 can remove this problem, please take a look?

[dmitryax]

#12484 can remove this problem, please take a look?

I'm not sure why would we allow random fields going forward. I would suggest the following:

1. update the mdatagen schema first, but don't enforce it
2. update usages in contrib
3. enforce it

[dmitryax]

Or we can just add Skip Contrib Tests until contrib is updated. PRs there can be ready in the "failing" state until this is merged

[ChrsMark]

#12484 can remove this problem, please take a look?

I'm not sure why would we allow random fields going forward. I would suggest the following:

1. update the mdatagen schema first, but don't enforce it
2. update usages in contrib
3. enforce it

I like this approach. I filed #12498 to update the schema without enforcing it.

[atoulme]

@ChrsMark please rebase this PR to fix conflicts, thanks!

[ChrsMark]

@ChrsMark please rebase this PR to fix conflicts, thanks!

Sure, will need to rebase anyways once/if #12498 gets merged.

[ChrsMark]

@atoulme shall we enable contrib tests again here?