Option to only propagate existing traces for more effective tracing rollouts

[william-tran]

When rolling out specialagent to existing, complex architectures, I'm finding that there are many traces that don't correspond to the use cases that intend to be traced. To make a tracing rollout more deliberate and to better show the initial value of tracing, it would be great to have an option for specialagent to only continue existing traces and not start new ones. The grunt work in tracing that auto-instrumentation helps with is trace propagation, and we'd continue to benefit from that with this option enabled. This option could be rule-specific as well.

Before:

1. Add specialagent to a set of services involved in a trace.
2. Check your tracing backend. You see the operation you wanted to trace starting at the ingress service, among lots of other traces from all services that are essentially noise.

After:

1. Add specialagent to a set of services involved in a trace.
2. Check your tracing backend. You don't see any traces yet.
3. In the ingress service, either a) use the opentracing API directly to create spans for each ingress operation, or b) set an option to allow only the spring-mvc rule to start new traces.
4. Check your tracing backend. You now see traces that correspond to the ingress operations that you intended to trace. If you did 3a), these ingress operations are named exactly as you named them.

[william-tran]

Alternatively, if using a Jaeger tracer, we could get the same thing by setting a default sampling strategy of probability 0, and having a whitelist of services + operations.

• https://www.jaegertracing.io/docs/1.17/sampling/