Registry manifest and Schema diff

[lquerel]

Note: The scope of this PR has been reduced to focus only focus on the schema diff feature. Github issues have been created to track the features that have been postponed #482, #483.

This PR implements the command registry diff, see the following example:

cargo run -- registry diff -r https://github.com/open-telemetry/semantic-conventions/archive/refs/tags/v1.27.0.zip[model] --baseline-registry https://github.com/open-telemetry/semantic-conventions/archive/refs/tags/v1.26.0.zip[model] --diff-format markdown

In this example, the diff is displayed in markdown format. The following formats are supported: json, yaml, markdown, ansi, ansi_stats

A detailed description of the schema diff data model and the diffing process is visible here.

Notes:

• The crate weaver_otel_schema is not essential for this PR; it was initially included as part of the preparations for the registry schema-update command. We have decided to implement this command in a future PR. However, for simplicity, I prefer to keep the preparation code in place instead of removing it. Same thing for all_changes in weaver_version.

List of modifications to apply to the semantic conventions repository after the release of the Weaver containing the current PR:

• Add a registry-manifest.yaml file with the version of the next release.
• Update all deprecated fields.

Closes: #186

[codecov]

Codecov Report

Attention: Patch coverage is 37.19008% with 228 lines in your changes missing coverage. Please review.

Project coverage is 70.9%. Comparing base (33bd40e) to head (6ba427c).

Files with missing lines	Patch %	Lines
crates/weaver_resolved_schema/src/lib.rs	0.0%	119 Missing ⚠️
crates/weaver_version/src/schema_changes.rs	0.0%	49 Missing ⚠️
crates/weaver_common/src/result.rs	0.0%	18 Missing ⚠️
crates/weaver_semconv/src/deprecated.rs	71.6%	17 Missing ⚠️
crates/weaver_otel_schema/src/lib.rs	43.7%	9 Missing ⚠️
crates/weaver_semconv_gen/src/lib.rs	70.5%	5 Missing ⚠️
crates/weaver_semconv/src/manifest.rs	90.3%	3 Missing ⚠️
crates/weaver_semconv/src/registry.rs	83.3%	3 Missing ⚠️
crates/weaver_common/src/diagnostic.rs	0.0%	2 Missing ⚠️
crates/weaver_resolver/src/registry.rs	83.3%	2 Missing ⚠️
... and 1 more

Additional details and impacted files

@@           Coverage Diff           @@
##            main    #400     +/-   ##
=======================================
- Coverage   74.1%   70.9%   -3.3%     
=======================================
  Files         50      54      +4     
  Lines       3946    4273    +327     
=======================================
+ Hits        2927    3032    +105     
- Misses      1019    1241    +222     

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

[lquerel]

@lmolkova @jsuereth

Note 1: I have addressed most of the feedback. The main task remaining is the removal of change detection for elements other than attributes. That will be done soon.

Note 2: I will also write a document describing: the format of the schema diff, examples of what can be done with it, the current limitations, and ideas for future development.

I have a question regarding the format of the new deprecated field. In the current version of this PR, a deprecated field can take one of the following three forms:

Old approach (still supported for compatibility reasons):

deprecated: "deprecation message"

or

deprecated:
  action: renamed
  renamed_to: attribute_name

or

deprecated:
  action: deprecated

With this, we can handle simple attribute renaming scenarios, as well as merge scenarios (e.g., A and B are renamed to C; Weaver will detect this automatically). However, we currently have no way to represent a split (e.g., A is renamed to B and C). So with the current implementation, the semconv author will need to set deprecated to action: deprecated and provide a note at the object level to explain the split in textual form.

We could make this explicit in the format of the deprecated field and in the diff output. This would allow for migration documentation that more accurately reflects the desired changes. However, it still wouldn’t enable automatic downgrades in the schema processor for the split scenario (at least without logic taking into account some additional context).

Question: Adding such an advanced definition for the deprecated field isn’t particularly complicated, so I don’t mind including it. What do you think? Are there other types of deprecations you’d like to codify?