Do not activate span since thread-local propagation does not work correctly when using cats-effect

[mwisnicki]

As mentioned in #1186 (comment) we should not be activating spans on thread local by default. This is incorrect when using IO.

The only safe way to do this is explicitly as in #1189.

Not activating spans is also consistent with other backends like OpenTelemetry.

[mwisnicki]

Any chance of getting this merged?

[kubukoz]

Perhaps if it's a Span.Options parameter? It'd also have to be ported to other backends. I think it's OK to roll with it as long as it's opt-in.

[mwisnicki]

Perhaps if it's a Span.Options parameter? It'd also have to be ported to other backends. I think it's OK to roll with it as long as it's opt-in.

@kubukoz I did try it at first but then realized it's never correct to have it enabled (i.e. it's a bug, you'll have spans attaching to random threads when fiber moves to different carrier thread) and also other backends don't do that: #1187 (comment)

[mwisnicki]

If someone needs this broken behavior for some reason they can always do this:

    entrypoint
      .root("foo")
      .flatTap(span =>
        Resource.make(Sync[F].delay(tracer.activateSpan(span.asInstanceOf[DDSpan[F]].span)))(s => Sync[F].delay(s.close()))
      )

[kubukoz]

ok, let's do it. @bpholt do you have any strong opinions on this?