Add owning version common::AttributeValue (e.g. common::event::Properties or common::event::Attributes)

[maxgolov]

Our Tracing API surface assumes that the common::AttributeValue here does not own the originating event attribute memory.

When I use the SDK to append some event on Span, e.g.

    std::map<nostd::string_view, common::AttributeValue> m;

Then use some utility function that returns a temporary std::string, e.g. std::string getSomeValue()

I cannot code my events this way:

    std::map<nostd::string_view, common::AttributeValue> m;
    m["Key1"] = getSomeValue();
    m["Key2"] = getSomeOtherValue();

Because nostd::string_view would refer to temporary that does not have any lifecycle guarantees.

Now to overcome this limitation, I could do the following:

    std::map<nostd::string_view, common::AttributeValue> m;
    auto val1 = getSomeValue();
    m["Key1"] = val1;
    auto val2 = getSomeOtherValue(); 
    m["Key2"] = val2;

Then emit my span attributes, which would be handled more coherently.

I wonder if we could create another class similar to OwnedAttributeValue in API, maybe naming it EventProperties or Properties or Attributes, being owning collection in order to simplify the usage of OpenTelemetry SDK. Without this concept it is very easy to fall into trap of a memory corruption on a temporary assigned to non-owning nostd::string_view.

As alternative, I'd like to show what could have been done to address this:
https://github.com/maxgolov/opentelemetry-cpp/blob/master/api/include/opentelemetry/event/Properties.hpp

This code is inspired by the following original implementation:
https://github.com/microsoft/cpp_client_telemetry/blob/master/lib/include/public/EventProperties.hpp

[lalitb]

If number of attributes are limited, we can use something like this: ( as temporaries live until end of full expression)

span.AddEvent(name , {"key1", getSomeValue()}, {"key2", getSomeOtherValue()}});

Having said that, In general - I do see the pain to create temporary variables to avoid memory corruption. However, introducing Owned-attributes will bringing the ABI stability issue, which was the initial reason of API design using non-owning attributes.