Experiment: ResourceValue as struct

[bruno-garcia]

An attempt to come up with a "union type" for the Resource Value.
Since this might be total crap, I'm opening a draft to discuss before investing time.

If we decided to move on with this, we'd need to discuss/consider:

1. When mapping attributes from OTel which have a value of type ResourceValue to a string like in the case of Zipkin, what would be correct behavior be? Is there any consideration to the ToString formatting of this or simply calling ToString on all the inner types is good enough?
2. Needs tests for validation and also using the API not only with string value but also the other types
3. Implement the correct types. Spec says: string, int64, double, bool.
4. Add in when taking ResourceValue as a parameter in the SDK/API.
5. Write some benchmarks (probably before anything) to make sure this isn't prohibitively slow.

[SergeyKanzhelev]

wait, should values be of various types, not keys?

[bruno-garcia]

/me hides

Ok now read the code as ResourceValue. Would that make sense?
Considering the TODO's of the description if we go ahead.
How do you plan to implement this
Updated the description.

[lmolkova]

Everywhere else (Span.Attributes) we simply use object as a type of value. There is a long discussion where we got rid of AttributeValue here. Major points are:

• There are more changes coming to attributes (arrays, maps and more Support map values and nested values for attributes opentelemetry-specification#376) and object would always work.
• Exporters can check attribute value for known types easily
• there is no reason to have it (i.e. it does not solve any issue)

Resource can validate that type is one of the expected and don't allow wrong things.

I prefer us to be consistent and not come up with the ResourceValue.

[bruno-garcia]

The only reason for this was to avoid boxing the value types.
Many strong reasons not to do this, so closing it.