Add property to allow autoconfiguration of SDK telemetry version

[anuraaga]

While discussing how to reflect telemetry version in declarative config in a cross-language way (open-telemetry/semantic-conventions#3293), it would be helpful to have a traditional config property for it to be able to roll out new metrics to javaagent users. This defines otel.experimental.sdk.telemetry.version to allow that.

#7928

[codecov]

Codecov Report

❌ Patch coverage is 82.85714% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.13%. Comparing base (b56bc54) to head (1123aa2).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
.../otlp/internal/InternalTelemetryConfiguration.java	57.14%	2 Missing and 1 partial ⚠️
.../autoconfigure/InternalTelemetryConfiguration.java	57.14%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8037      +/-   ##
============================================
- Coverage     90.16%   90.13%   -0.04%     
- Complexity     7478     7484       +6     
============================================
  Files           834      836       +2     
  Lines         22559    22588      +29     
  Branches       2239     2246       +7     
============================================
+ Hits          20341    20360      +19     
- Misses         1515     1524       +9     
- Partials        703      704       +1     

☔ 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.

[jack-berg]

Looks good. As a principle, I / we want to make sure that declarative config is a strict superset of what's possible with env vars / system properties, so we'll want to make sure that #7928 is also resolved on the declarative config side of things as well.

[jack-berg]

#nit if we're not going to assert on the attributes, maybe a more terse assert syntax

Suggested change

	.anySatisfy(
	scopeMetrics -> {
	assertThat(scopeMetrics.getScope().getName())
	.isEqualTo("io.opentelemetry.sdk.logs");
	assertThat(scopeMetrics.getMetricsList())
	.satisfiesExactlyInAnyOrder(
	metric ->
	assertThat(metric.getName())
	.isEqualTo("otel.sdk.log.created"),
	metric ->
	assertThat(metric.getName())
	.isEqualTo("otel.sdk.processor.log.processed"),
	metric ->
	assertThat(metric.getName())
	.isEqualTo(
	"otel.sdk.processor.log.queue.capacity"),
	metric ->
	assertThat(metric.getName())
	.isEqualTo("otel.sdk.processor.log.queue.size"));
	})
	.anySatisfy(
	scopeMetrics -> {
	assertThat(scopeMetrics.getScope().getName())
	.isEqualTo("io.opentelemetry.sdk.logs");
	assertThat(
	scopeMetrics.getMetricsList().stream()
	.map(Metric::getName)
	.collect(Collectors.toSet()))
	.isEqualTo(
	new HashSet<>(
	Arrays.asList(
	"otel.sdk.log.created",
	"otel.sdk.processor.log.processed",
	"otel.sdk.processor.log.queue.capacity",
	"otel.sdk.processor.log.queue.size")));

Or maybe even something like maintaining a Map<String, Set<String>>, with keys of each expected scope and values being the set of metric names expected for that scope.

Not critical, but this test does get pretty long with so many verbose asserts.

[anuraaga]

Good call - I added a helper too, it seems to be both much smaller and more readable

[jack-berg]

Too bad we need two copies of this code. Maybe each can have a note in the javadoc referencing the other to increase the chance of keeping changes in sync?

[anuraaga]

Yeah added the references