refactor: make clock decoupled from rdsn runtime

[levy5307]

The clock API, is tightly coupled in rdsn runtime for historical issues. As a part of the long-term plan of rdsn (see #141 ) we decoupled it to make further refactoring possible.

[neverchanje]

咱们以后架构是这样的：

 dsn_runtime
  +  +  +
  |  |  |
 <+  v  +>
aio rpc task ...
  +  +   +
  v  v   v
 dsn_utils

这个架构图应该很清楚了，模块之间应该相互隔离，dsn_utils 要和 rpc/task/aio 隔离开，你要以这个为目的来写。

clock 原来是放在 dsn_runtime 里面的，那么你要使用 clock，你就要依赖 rpc/task/aio + dsn_utils，但这样是不对的，clock 应该放在 dsn_utils 里面，这样能你用 clock，你只需要依赖 dsn_utils。

所以

1. 你的实现不能依赖于 native_run，native_run 顾名思义是 runtime 的意思。
2. clock.h 应该放在 dsn/utility 下面，不应该放在 tool-api 里面，tool-api 是放 runtime 的各种组件接口。
3. dsn_now_ns 不应该依赖 src/core/core/service_api_c.cpp，因为 service_api_c 这个文件明显是包含 rpc 等等方法的。

[levy5307]

咱们以后架构是这样的：

 dsn_runtime
  +  +  +
  |  |  |
 <+  v  +>
aio rpc task ...
  +  +   +
  v  v   v
 dsn_utils

这个架构图应该很清楚了，模块之间应该相互隔离，dsn_utils 要和 rpc/task/aio 隔离开，你要以这个为目的来写。

clock 原来是放在 dsn_runtime 里面的，那么你要使用 clock，你就要依赖 rpc/task/aio + dsn_utils，但这样是不对的，clock 应该放在 dsn_utils 里面，这样能你用 clock，你只需要依赖 dsn_utils。

所以

1. 你的实现不能依赖于 native_run，native_run 顾名思义是 runtime 的意思。
2. clock.h 应该放在 dsn/utility 下面，不应该放在 tool-api 里面，tool-api 是放 runtime 的各种组件接口。
3. dsn_now_ns 不应该依赖 src/core/core/service_api_c.cpp，因为 service_api_c 这个文件明显是包含 rpc 等等方法的。

1.我觉得我这个实现是不依赖native_run的，从依赖关系来看，其实是native_run依赖clock。这个nativerun里留了个new clock有一定迷惑性，我的意思是想表达各种不同的runtime可以根据自身需要创建自己需要的clock。这个实现有点c-style，就像上面我说的，因为我觉得写成单例那种方式，由于mock接口的存在导致clock就不是线程安全的。所以干脆没暴露这个接口，当然我这样确实有点tricky，大家可以帮忙再看看有没有比较好的方案
2.我不是很清楚为啥tool-api是放runtime的各种接口？还有tool-api和utility有什么区别？对于tool和utility的区别，我的理解是utility就是一些和逻辑完全无关的工具实现。tool里是和逻辑有一定关系的，我看sim_clock是和我们逻辑有关系的，所以就把clock和sim_clock都放到tool里面了
3.第三条这个，service_api_c中是不是以后要把rpc抽出去？我不太清楚service_api_c这个文件以后的定位是干啥的

[neverchanje]

由于mock接口的存在导致clock就不是线程安全的

如果你允许各个模块都调用 clock::mock()，那各个模块同时调确实会存在线程安全问题。但如果是只有 simulator 一个模块调用就没这个问题，只有一个调用方那么肯定没有并发，又何来线程安全问题。你可以在 clock::mock 注释上标明 "not thread-safe"。

我不是很清楚为啥tool-api是放runtime的各种接口？还有tool-api和utility有什么区别？对于tool和utility的区别，我的理解是utility就是一些和逻辑完全无关的工具实现。tool里是和逻辑有一定关系的，我看sim_clock是和我们逻辑有关系的，所以就把clock和sim_clock都放到tool里面了

你可以看 tool-api 下都有哪些代码，你就应该能分清楚 tool-api 和 utility 的关系。里面有 rpc/aio/task 的文件，例如 network.h，aio_provider.h，那么很显然 tool-api 对应是 dsn_runtime。那么你从代码读者的角度考虑，肯定就不能把 clock 放在 tool-api，那不然不是把鸡放在猪圈里了吗？

我不太清楚service_api_c这个文件以后的定位是干啥的？

还是跟上面一样，看 service_api_c 里面有哪些代码，显然里面有 rpc 模块，还有 dsn_run 等等，显然是对应 runtime 的一个杂烩的文件。

service_api_c中是不是以后要把rpc抽出去？

上面说了，我们要把 rpc/aio/task 从 dsn_runtime 隔离出来，所以是的。