add IsRemote field to SpanContext, set by propagators

[tsloughter]

Without a field to mark if a SpanContext came from a remote process Span creation and sampling can not know if the new span has a remote parent.

This PR adds a IsRemote field to SpanContext and defines that it must be set when deserializing a propagated SpanContext.

This is additionally important for implementations that can not pass the parent Span as an argument to startSpan but only a SpanContext. That is the case with the Erlang/Elixir implementations because the content of a Span is kept in a table (since it needs to be able to be mutated) while the SpanContext is an immutable record.

Closes #187

[bogdandrutu]

@tsloughter let's wait couple of days until we put the RFC for sampling, the hasRemoteParent may be removed, otherwise I really like this proposal if the remote parent stays.

[tsloughter]

@bogdandrutu ok, sounds good. Curious to see the sampling RFC.

[bogdandrutu]

Please see the RFC proposal open-telemetry/oteps#24

[tsloughter]

Now that the sampling rfc has been merged is this ready?

[songy23]

How about HasRemoteParent? IsRemote sounds like describing the property of a span context itself, rather than its parent.

[yurishkuro]

it is indeed the property of the context itself. E.g. in this OpenTracing example:

ctx = tracer.extract(Format.HTTP, request.headers)
span = tracer.startSpan('name', childOf=ctx)

the ctx here is "remote".

[Oberon00]

If that boolean is contained in the SpanContext, I'd remove the extra argument altogether.

[tsloughter]

Good point, probably can remove the boolean argument.

[Oberon00]

What about, instead of a boolean, the SpanContext having an optional reference to the in-process Span, null meaning that it is remote?

[tsloughter]

@Oberon00 that is an interesting idea since in the Erlang impl I currently do similar. The term stored when a span is created is {SpanCtx, Parent} where Parent is another {SpanCtx, Parent} and so on. This allows for easily making the parent the current span context when finishing a span.

[bogdandrutu]

@Oberon00 Having a reference to the "Span" causes a circular dependencies because Span also has a reference to the SpanContext. I think we should not do that.

[Oberon00]

Span also has a reference to the SpanContext

Not necessarily. It could just store the required info directly (or in some SpanContextData object that is equivalent to SpanContext minus back-reference) and create a SpanContext on demand.

Also, I don't think a circular dependency is really a problem here, Span and SpanContext are closely related anyway.

[yurishkuro]

@tsloughter do you mind elaborating why you need isRemote? What would startSpan do differently?

[tsloughter]

@yurishkuro it is used in the probability sampler https:/open-telemetry/oteps/blob/eeab6a2d1342abb58ad5e7c0aadaaa4b1ab32310/text/0006-sampling.md#default-samplers

Allows users to configure if probability applies only for "root spans", "root spans and remote parent", or "all spans".

    Default is to apply only for "root spans and remote parent".
    Remote parent property should be added to the SpanContext see specs PR/216

[yurishkuro]

I would suggest putting the circular reference discussion aside, as it is not related to this issue, only as an implementation detail. If we want to support configurable upsamping scenarios at "local root" spans, and expose it via sampling API (not just implementation), then we need isRemote in the API.