otelconf: introduce support for v1.0.0-rc.2

[codeboten]

This adds support for the second 1.0.0 release candidate of the OpenTelemetry configuration schema. The edits in this PR:

1. update OPENTELEMETRY_CONFIGURATION_JSONSCHEMA_VERSION
2. run make genjsonschema

First part of #8026

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.6%. Comparing base (1f2dffe) to head (02c4c4e).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #8031   +/-   ##
=====================================
  Coverage   78.6%   78.6%           
=====================================
  Files        185     185           
  Lines      14760   14760           
=====================================
  Hits       11611   11611           
  Misses      2795    2795           
  Partials     354     354           

🚀 New features to boost your workflow:

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

[codeboten]

updated the candidate to rc2 since there's no point in introducing schema support for rc1 with rc2 already out

[dmathieu]

I wonder if we want to name this module rcx. The package is unstable, so it can have breaking changes.
Couldn't we name 1.0.0, and add any change that would happen before the final release into a single module?

[codeboten]

I wonder if we want to name this module rcx

i had the same question when i opened this pr. i guess one of the challenges is that anyone using 1.0.0rcx wouldn't be able ensure that any config they've written would work with updates to rcx, which would be problematic if someone just happens to pick up a dep update that includes a breaking change but isn't expecting it.

at least with rc.2 and whatever subsequent versions, there would be some stability for end users of the package, even though we make no guarantees of stability at this point

[codeboten]

Multiple RCs is more code though, but we could always mark the package deprecated as soon as the new rc is out.

[codeboten]

Not sure if we want a changelog for this specific change as the generated code as-is cannot be used on its own

[dashpole]

Can you remind me why we need to support multiple versions? Could we not put the 1.0 (including RCs) in otelconf itself?

[codeboten]

Needed the multiple versions to support backwards incompatible changes between versions in the collector. The collector supports both v0.2.0 and v0.3.0 configuration at this point, and my plan was to eventually only support 1.0 configuration, but it will need feature gates in the collector and deprecation warnings for end users.

[dashpole]

Can we leave 0.2 and 0.3 as separate directories with their own module and put the 1.0 RCs (and 1.0) in the base /otelconf directory. Then eventually otel-go marks the 0.2 and 0.3 modules as deprecated and removes them, but gives the collector enough time to migrate? That way, we eventually get back to the place of having just one stable entry-point to the otelconf library. People complain about our semconv code structure a lot, so I would rather avoid that long-term if possible

[codeboten]

@dashpole change has been made, the generated code is now in the root of the package. i'll update the makefile to change the destination of the generated code in a follow up PR

also updated the makefile to generate the code in this location