Stabilize log any value

[jack-berg]

Resolves #6581. Unblocks #6509.

• Promote AnyValue from the incubating artifact to the stable API. Moved it to the io.opentelemetry.api.common package because while its only usage is in the log API today, its possible that future otel APIs reuse the more generic AnyValue representations.
• On the SDK side, deprecate the Body class. It serves the same function as AnyValue, but really should have been in the API package from the start. Since its not, retaining Body and extending it to represent AnyValue concepts results in a cumbersome API with an unnecessary layer of abstraction (i.e. Body encloses AnyValue encloses your data). Instead we have a new LogRecordData#getAnyValueBody() method which represents all the different body types. Steps are taken to ensure users relying on LogRecordData#getBody() are not impacted, and continue to get a functional string representation even when the body is an AnyValue.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 81.39535% with 32 lines in your changes missing coverage. Please review.

Project coverage is 90.03%. Comparing base (7522bfe) to head (9764054). Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
...ntelemetry/sdk/testing/logs/TestLogRecordData.java	10.00%	9 Missing :warning:
...va/io/opentelemetry/sdk/logs/SdkLogRecordData.java	0.00%	4 Missing :warning:
...java/io/opentelemetry/api/common/KeyValueList.java	86.95%	1 Missing and 2 partials :warning:
...n/java/io/opentelemetry/api/common/ValueArray.java	81.25%	1 Missing and 2 partials :warning:
...va/io/opentelemetry/api/logs/LogRecordBuilder.java	0.00%	2 Missing :warning:
...etry/exporter/internal/otlp/AnyValueMarshaler.java	77.77%	1 Missing and 1 partial :warning:
.../io/opentelemetry/sdk/logs/data/LogRecordData.java	0.00%	2 Missing :warning:
...java/io/opentelemetry/api/common/ValueBoolean.java	80.00%	0 Missing and 1 partial :warning:
...n/java/io/opentelemetry/api/common/ValueBytes.java	80.00%	0 Missing and 1 partial :warning:
.../java/io/opentelemetry/api/common/ValueDouble.java	80.00%	0 Missing and 1 partial :warning:
... and 4 more

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6591      +/-   ##
============================================
- Coverage     90.09%   90.03%   -0.06%     
+ Complexity     6280     6277       -3     
============================================
  Files           697      697              
  Lines         18951    18939      -12     
  Branches       1858     1864       +6     
============================================
- Hits          17073    17051      -22     
- Misses         1305     1314       +9     
- Partials        573      574       +1     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[jack-berg]

can we avoid the deprecations by adding an AnyValueBody subtype of Body?

This is what I was originally intending on doing, but see my comment in the PR description:

On the SDK side, deprecate the Body class. It serves the same function as AnyValue, but really should have been in the API package from the start. Since its not, retaining Body and extending it to represent AnyValue concepts results in a cumbersome API with an unnecessary layer of abstraction (i.e. Body encloses AnyValue encloses your data). Instead we have a new LogRecordData#getAnyValueBody() method which represents all the different body types. Steps are taken to ensure users relying on LogRecordData#getBody() are not impacted, and continue to get a functional string representation even when the body is an AnyValue.

In this PR, getBody() continues to work by relying on AnyValue.asString() to provide a string encoding of complex types, but the new getAnyValueBody() is preferred. If I could do it all over again, I would have had the foresight to put Body in the api package from the start and avoided this problem.

[jack-berg]

some (probably unhelpful) thoughts on naming: AnyValue -> Value AnyValueType -> ValueType KeyAnyValue -> KeyValue or Entry getAnyValueBody -> getBodyValue

Thanks for the suggestions. I do like these. The one consideration I have is that the Any* prefix more strongly indicates a direct relationship with the protobuf AnyValue type. Is this valuable enough to justify the increased verbosity?

[jack-berg]

Ended up implementing trask's naming recommendations, which ballooned the size of the PR but is probably best in the long term.

[jack-berg]

@trask / @jkwatson any intent to spend additional time reviewing before I merge?

[jkwatson]

@trask / @jkwatson any intent to spend additional time reviewing before I merge?

I unfortunately won't have time. Make it so.

[jack-berg]

FYI, planning on merging later today.