[mdatagen] add deprecation start date and migration instructions

[atoulme]

Component(s)

No response

Describe the issue you're reporting

When setting the status of a component to deprecated, mdatagen should validate the presence of two additional fields in metadata.yaml:

• One field that contains the date of the deprecation, in format YYYY-MM-DD ("2006-01-02" date parsing format)
• One field that contains a non empty string with migration instructions. This is a free form field. It is reasonable for someone to enter "No migration is offered for this component", and reviewers of the change can discuss.

Those fields should surface in the README.md generated text.

[ChrsMark]

Hey @atoulme, I'd like to help with that. Could I get assigned (if that's not urgent)?

ps: before any implementation I think we should decide on the schema, where these fields will be placed.

[atoulme]

Sure, go ahead. Thank you!

[ChrsMark]

One field that contains the date of the deprecation, in format YYYY-MM-DD ("2006-01-02" date parsing format)
One field that contains a non empty string with migration instructions. This is a free form field. It is reasonable for someone to enter "No migration is offered for this component", and reviewers of the change can discuss.

I gave some thought to this and I wonder if/how we should ensure that signal specific deprecation can be covered.

At the moment the deprecated field can take multiple values as a list, i.e. deprecated: [traces, metrics, logs]. So, what if traces signal was deprecated on February 1st while metrics on March 1st? I assume this'd be possible.
If this is possible then we would need to support a list of deprecation dates, something like deprecation_date: [traces_2025-02-01, metrics_2025-03-01].

For the migration instruction field I think it's not that tricky since it's a free form field so it can contain multiple paragraphs to cover the various signal types.

@atoulme any thoughts here?

[atoulme]

You are right that it can be per signal. I would ask that it be machine readable such that the date is its own field, maybe:

deprecation:
  traces: 
    date: 2012-12-01