Propagate Tracer when building TChannel

[natemort]

While workflows still capture the tracing information in the headers, we should pass the Tracer to TChannel so that we correctly trace all RPC requests sent to the Cadence server.

Ensure that Tracer can't be set to null and correct the testing library version to avoid classpath conflicts.

What changed?

• Pass Tracer to TChannel
• Change default Tracer to GlobalTracer, which defaults to NoopTracer

Why?

• Ensure full tracing support
• Enable tracing by default if the runtime environment has a default Tracer.

How did you test it?

• Unit and integration tests

Potential risks

• Cadence creates redundant spans as part of its own tracing implementation. These are somewhat incorrect, but it would take significant work to remove. This is true for the go-client as well.
• Cadence's gRPC implementation doesn't have an immediate equivalent to this and requires users to pass a ManagedChannel that already has an equivalent interceptor. Users migrating from TChannel to gRPC may see a regression if they similarly allow Cadence to construct the transport.

Release notes

Documentation Changes

[abhishekj720]

Overall LGTM with a minor comment about explanation of reason of downgrading opentracing-mock

[abhishekj720]

why opentracing-mock is pinned to 0.32.0 (what conflict it avoids)?

[natemort]

The TChannel version we're using at runtime uses the opentracing 0.32.0 core libraries. This test dependency ends up overwriting that, making our tests run against opentracing 0.33.0 core.

There was a breaking change in opentracing, so the tests all fail after the Tracer is added because the method they call no longer exists.

This change corrects the test version to match what we actually run against. It's a test dependency of the java client, so it doesn't impact users at all.