Span start/end after parent and trans end should be allowed (elastic#635

)

specs/agents/handling-huge-traces/tracing-spans-limit.md

@@ -42,7 +42,10 @@ In this case the above mentioned counter for `reported` spans is not incremented
 }
 ```
 
-The total number of spans that an agent created within a transaction is equal to `span_count.started + span_count.dropped`. 
+The total number of spans that an agent created within a transaction is equal to `span_count.started + span_count.dropped`.
+Note that this might be an under count, because spans that end *after* their
+transaction has been reported (typically when the transaction ends) will not be
+counted.
 
 ### Checking the limit
 
@@ -57,7 +60,7 @@ On span end, agents that support the concurrent creation of spans need to check
 That is because any number of spans may be started before any of them end.
 
 ```java
-if (atomic_get(transaction.span_count.eligible_for_reporting) <= transaction_max_spans // optional optimization 
+if (atomic_get(transaction.span_count.eligible_for_reporting) <= transaction_max_spans // optional optimization
     && atomic_get_and_increment(transaction.span_count.eligible_for_reporting) <= transaction_max_spans ) {
     should_be_reported = true
     atomic_increment(transaction.span_count.reported)
@@ -81,7 +84,7 @@ the value that has been read at the start of the transaction should be used.
 ### Metric collection
 
 Even though we can determine whether to drop a span before starting it, it's not legal to return a `null` or noop span in that case.
-That's because we're [collecting statistics about dropped spans](tracing-spans-dropped-stats.md) as well as 
+That's because we're [collecting statistics about dropped spans](tracing-spans-dropped-stats.md) as well as
 [breakdown metrics](https://docs.google.com/document/d/1-_LuC9zhmva0VvLgtI0KcHuLzNztPHbcM0ZdlcPUl64#heading=h.ondan294nbpt)
 even for spans that exceed `transaction_max_spans`.
 

specs/agents/tracing-spans.md

@@ -8,6 +8,9 @@ Each span object will have an `id`. This is generated for each transaction and
 span, and is 64 random bits (with a string representation of 16 hexadecimal
 digits).
 
+Each span will have a `parent_id`, which is the ID of its parent transaction or
+span.
+
 Spans will also have a `transaction_id`, which is the `id` of the current
 transaction. While not necessary for distributed tracing, this inclusion allows
 for simpler and more performant UI queries.
@@ -143,3 +146,15 @@ following are two options how to do that:
 - Add a denylist of span `type` and/or `subtype` to identify exit spans of which underlying protocol supports context propagation by default.
 For example, such list could contain `type == storage, subtype == s3`, preventing context propagation at S3 queries, even though those rely on HTTP/S.
 - Add a list of child IDs to compressed exit spans that can be used when looking up `parent.id` of downstream transactions.
+
+### Span lifetime
+
+In the common case we expect spans to start and end within the lifetime of their
+parent and their transaction. However, agents SHOULD support spans starting
+and/or ending *after* their parent has ended and after their transaction has
+ended.
+
+This may result in [transaction `span_count` values](handling-huge-traces/tracing-spans-limit.md#span-count)
+being low. Agents do not need to wait for children to end before reporting a
+parent.
+