Span should support creation with lazy links

[lmolkova]

No description provided.

[bruno-garcia]

On #273 there's a link to the new approved sampling spec. There under TLDR it says:

Remove addLink APIs from the Span interface, and allow recording links only during the span construction time.

Maybe I don't understand this issue but does it conflict with the quite above?

[lmolkova]

no, links should be provided in StartSpan, but not later.
Today we only have API that accepts array of links, which leads to open-telemetry/opentelemetry-specification#305

So here, we need to remove Span.AddLink and find a nice way to accept Func<IEnumberable<Link>> on span creation.
Open question: do we need to keep overloads that accepts IEnumerable

[bruno-garcia]

If we take a Func<IEnumerable<Link>>, we'd pass it along to the sampling decision and in case the span is sampled in, we'd need to invoke the func again to get links?

Do you see a way around that?
We could take a type (like LinkProvider) which takes the Func in the constructor and caches the value if invoked. This way if the sampler does invoke it, the value is kept in the instance and can later be used by the SDK.
Downside is that now we allocate the LinkProvider and also the Func<> for each Span.

[lmolkova]

Noop impl will ignore func. Sdk will invoke lambda to make sampling decision - you have to know links to make it.

The only thing lambda protects from is perf impact for noop case.

[bruno-garcia]

Right. But one time we'll give the Func<> to ISampler. That'll invoke it to decide whether to sample or not.

Then it returns true and we need to populate the Span.Links so we'll need to invoke the Func<> again.

[SergeyKanzhelev]

@lmolkova @bruno-garcia Is there anything left here after #282?

[lmolkova]

this is done in #282.