TraceState/Baggage fields currently should only accept string-string pairs

[MrAlias]

Currently they use the label.KeyValue. This is out of compliance with the spec.

[humivo]

Hello I would like to take on this issue

[Aneurysm9]

@MrAlias I don't see a linked PR, so I'm going to assume you're fine with someone taking this off your hands!

[MrAlias]

Notes from SIG meeting (2021-04-01):

• It is not ideal to change the interface to a string and not unify on a single attribute type.
• Our attributes currently already have conversions to a string. If we want to keep this conversion we would need to have this conversion specified at the specification level.

[MrAlias]

Talking with Bogdan it was made clear we want the TraceState to not include type. There is no way to interpret a value when deserializing as a particular type.

If we include a type it could lead to user expectation that we will correctly deserialize the type of their choosing. Meaning, for example, they create some enum type with a base type of an int and serialize that value it will become a string representation of an int, but when they deserialize it and expect it to be interpreted as the original type the string will not be interpreted as such and cause an error. The explicit expectation that the user handle the conversion becomes clear when we only support string values.

This may also be the same for baggage, but with the recent unification of attributes in metrics, there may be a situation where we want baggage to be transformed into attributes. Meaning that types may need to be communicated in the baggage. We are still exploring if this is a potential for the future and will plan based on findings.

[MrAlias]

Regarding the baggage rework, it was pointed out today in the SIG meeting that if we restructure the Baggage to handle metadata and revert to just using strings we can always add on another layer that looks for type information (if it becomes available) and abstract that back to our KeyValue type.