Use semantic conventions v2 for weaver registry infer

[ArthurSens]

Continuing the work we agreed on, this PR migrates the weaver registry infer command to the schema file's second version.

There are a few open questions from my side, which I'd love some input from maintainers:

• From an OTLP message with Resource Attributes, but no EntityRef fields populated, should we be creating a single entity with all attributes as identifying? Should we not create Entities at all? In v1, we created a single resource group, but I'm not sure what to do in v2.
• For Spans, I'm using the span name for both span.type and span.note. Should I be using something else for them?
• I know span events will be deprecated, but for now, I'm joining span events and log events with the same name into the same Event record. Is that ok?

[codecov]

Codecov Report

❌ Patch coverage is 93.12977% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.9%. Comparing base (173fed7) to head (c68584b).

Files with missing lines	Patch %	Lines
crates/weaver_infer/src/lib.rs	92.1%	9 Missing ⚠️

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #1334   +/-   ##
=====================================
  Coverage   81.8%   81.9%           
=====================================
  Files        119     119           
  Lines       9938   10021   +83     
=====================================
+ Hits        8139    8211   +72     
- Misses      1799    1810   +11     

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jsuereth]

From an OTLP message with Resource Attributes, but no EntityRef fields populated, should we be creating a single entity with all attributes as identifying? Should we not create Entities at all? In v1, we created a single resource group, but I'm not sure what to do in v2.

You can either create one entity with everything or none. I think I'd prefer none until we get Entity populated, but I can see having something inferred better than nothing. We'll also need to deal with "loose" attributes for some time, so we should probably figure out the right behavior here.

For Spans, I'm using the span name for both span.type and span.note. Should I be using something else for them?

We don't have a formal span.type in OTLP yet, so that behavior is probably the right way to go for now, and we can evolve the span.type over time.

I know span events will be deprecated, but for now, I'm joining span events and log events with the same name into the same Event record. Is that ok?

YES! I think that should even help us with the migration from span-event to just event.

[jsuereth]

Is there a reason this is different than the actual struct/type we use for V2?

This seems to mostly by copy-paste from here - https://github.com/open-telemetry/weaver/blob/main/crates/weaver_semconv/src/v2/mod.rs#L54

You should be able to directly use that struct and wrap it in Versioned::V2(...struct...) when you need the manifest version.

[ArthurSens]

Mostly because it was all private in that crate. I've implemented constructors and accessors for it now :)

[ArthurSens]

Comments addressed!