allow parent/child transaction ids

[rabbah]

A transaction id allows us to trace the lifetime of a request handler through out the system. Some requests - sequence activation - have longer lifetimes and generate internal requests which inherit the same id. It is helpful if we however record sub requests with new transaction ids.

[markusthoemmes]

FWIW: OpenTracing seems to have this notion by default, maybe it's viable to fuse our transaction tracing with something more broad in the same manner?

[jkremser]

FYI, I've done that for you in this PR that you rejected probably because of other incompatible PR with Zipkin-specific tracing

[rabbah]

@jiri-kremser Could we seperate the two if it makes sense to do that?

[jkremser]

@rabbah you mean break the PR 2413 into two pieces? (One adding open-tracing for simple actions and the second one for the compound actions)

[rabbah]

@Jiri-Kremser i had a chance to review #2413 again. Indeed the invoke next action in a sequence generates a new span. I think this is close but also wondering if 1. can we bury the span inside a transaction id, and 2. we use somehow ties the start/end markers in so we don't have two mechanism doing the same thing.

It may be best to separate 1 & 2 in terms of the doing the work on the implementation but it makes sense to me to think about both in terms of the design.