Adds FAQ on ParentSpanId

[codefromthecrypt]

cc @openzipkin/core @openzipkin/instrumentation-owners This is an overdue section, which underpins a frequently asked question.

A follow-up will explain the single-host-span model which tosses this field.

[codefromthecrypt]

current status: so far B3 doesn't discuss that traces are a graph explicitly. It might be helpful to explain that parent-child is required to model the original call graph. then we wouldn't have to explain here the same thing.

[codefromthecrypt]

Removed nuance about storage impact of attempting to go without a parent, as it distracted from the more general point.

Here's the nuance discussion just as a log:

The parent span id is propagated to eliminate ambiguity about if a span is a root or not. It also removes a race condition creating the span (since the server often completes before its client processes the response).

If the server reported the span without its parent, the tracing system would likely assume it is a root span (a root is a span with no parent). The tracing pipeline could delay write until it is known whether the span had a client or not. However such an approach would imply consistent routing on trace ID and also state to keep these mappings. The simpler approach is to propagate the ParentSpanId when present. This removes the race condition and confusion around if a span is a root or not.

[codefromthecrypt]

@jcarres-mdsol @shakuzen PTAL I think it is more accessible now, but check me

[codefromthecrypt]

+```

• ┌───────────────────┐
• Incoming Request Headers │ TraceContext │ +┌───────────────────┐ │ ┌───────────────┐ │ +│ XXXX─TraceId │─────────┼─┼> TraceId │ │ +│ │extract()│ │ │ │ +│ XXXX─SpanId │─────────┼─┼> ParentSpanId │ │ +└───────────────────┘ │ │ │ │ ┌──────────────┐
• │ │ SpanId <┼─next()─│ ID Generator │

First box is a service (probably) , second box is a service but third box is functionality inside a library. That makes it confusing

no the first box is headers the second box is a trace context and the last is an ID generator. they are all things the tracer would be acting on. ex in ruby, they would be...

env[:request_headers] Trace::TraceId TraceGenerator

[codefromthecrypt]

clarified diagram as a library diagram (as opposed to a service one). added a diagram to show the difference. pruned words a bit taking suggestions from @jcarres-mdsol

third time's a charm? :)

[codefromthecrypt]

since this is editing text, we can do more edits later if needed. thanks for the reviews!