opentelemetry::logs::AnyValue is missing a None variant

[FSMaxB]

According to https://opentelemetry.io/docs/specs/otel/common/attribute-type-mapping/:

If the source data has no type associated with it and is empty, null, nil or otherwise indicates absence of data it SHOULD be converted to an empty AnyValue, where all the fields are unset.

This is currently unrepresentable with opentelemetry::logs::AnyValue, I suggest adding a new None variant and serializing that accordingly.

[djc]

Makes sense -- are you able to submit a PR? Seems like a straightforward addition.

[FSMaxB]

I can probably submit a PR within next week. Feel free to ping me again if it hasn't happened by then.

[FSMaxB]

Is there any reason why both opentelemetry::Value and opentelemetry::logs::AnyValue exist btw.? It seems to me that they should be the same type. (at least according to protocol buffers, they are the same type)

[djc]

@lalith @vibhavp can we remove logs::AnyValue in favor of the normal Value?

[lalitb]

As per the log data model - the attribute value can be an array of Any values i,e can have heterogenous values. While the Span attributes can only have an array of homogenous primitive values. This was the reason to keep them separate. I guess the proto uses AnyValue::ArrayValue which can be used to store either of these types of values.

[FSMaxB]

Ok, this also answers the next question I had, which is whether I should add None to Value as well, the answer is no:

Attribute values of null are not valid and attempting to set a null value is undefined behavior.

[hdost]

Is this related? open-telemetry/opentelemetry-specification#3826

[pellared]

I think it is related to this one: open-telemetry/opentelemetry-specification#3853

[cijothomas]

@lalitb Can you check if this is required for stabilizing Logs?