Proposal: Context与Tracing

[flycash]

What would you like to be added:

目前来说，从可观测性的角度讲，我们dubbogo的tracing还是做得不够，尚未与各种tracing框架集成。

因此我们近期计划完成这个事情。主要思路是：

1. 使用opentracing作为API抽象。这里面的关键在于，在使用了opentracing作为API之后，我们将不会定义自己的tracing的API。即如果某个tracing框架支持opentracing，那么可以直接使用；如果某个tracing框架不支持opentracing，那么我们将考虑开发一个适配层。之所以我不想自己定义一套dubbogo tracing的API，最为主要的就是我不觉得我有能力能够定义一套比opentracing更好的API；
2. 允许用户直接设置其GlobalTracer，也可以通过配置少量的参数，我们代为创建GlobalTracer。例如用户可以通过仅仅配置zipkin的endpoint等少数参数，我们代为创建出来GlobalTracer；又或者如果用户需要高度自定义的zipkin Tracer，那么他可以自己创建自己的Tracer并设置为GlobalTracer；
3. Context端到端的传递，其原则是：如果已有通用方案，比如说grpc，那么直接使用已有方案；如果没有方案，比如说dubbo protocol，那么则需要设计协议头。（可参考grpc和kratos）的协议设计；

在Tracing开发过程中，我们不得不面对另外一个问题，即Context的问题。目前我们的dubbogo的接口，欠缺一个贯穿整个调用过程的Context，即上下文。这里有三个点：

1. 目前在Url里面有一个context，但是该context并非线程安全。而且目前只设置了值，但是未被使用过，所以计划删除；
2. 在Invocation里面暴露一个Context接口。Invocation作为一个调用的抽象表示，放置Context是最为合适的；
3. 是否需要对Context进行分装？从长远考虑，对golang自带的Context进行封装是有价值的，可以带来更多的灵活性。在golang的组合语言特性之下，封装不会带来特别大的负担；