core: remove io-per-queue's io mode & fastrun's running mode

[shengofsun]

删除了难懂的、可能有bug、我们也基本用不上的fastrun和io-per-queue。因为想要fastrun得允许一个进程下开多个socket端口。删除之后，rdsn的初始化流程可以得到比较大的简化。

fastrun下的moodycamel_queue保留了下来，性能优化的时候可能用得着。

移除io-per-queue后，之前timer-service改成了io-per-node, 也就是全局一个timer线程。根据运行情况来看基本没有影响，timer线程比较闲，观察都是Sleep状态，cpu利用率大概20%左右。也可以从这个角度来推想：我们的aio thread也是全局只有一个的，也没有成为系统的瓶颈。这个带来的好处是，系统的总线程数减少了非常多。

经过测试发现：全局共用一个timer线程，写性能会大概有3%~5%的下滑。稍微调整了一下代码，将io-per-queue的方式内置到了每个threadpool内部，这样就和线上的运行方式一致了。

把timer-servce内置到threadpool里面后，rdsn的thread local就没必要export出timer service的接口了，service node也没有必要保留timer service的接口了，所以从这些地方里把他们移除掉了。

[neverchanje]

问几个问题哈:

1. src/core/core/task_engine.cpp 这里, 我理解是每个线程池的每个 queue 都配一个 timer_service.
   所以可以说, 如果线程池有 10 个 worker 线程, 并且这个线程池是 partitioned, 那它就有 10 个 timer service ? 并且如果它不是 partitioned, 那它只有 1 个 timer service ?

2. 既然 timer_service per task_queue 还在, 那现在还支持 timer_service per service_node 吗?

[shengofsun]

@neverchanje

1. 恩恩，就是这样的。现在线上也是这么做的。测试的结果是，这么搞貌似性能会高个一丢丢(3%~5%)，虽然线程会多很多。我这边也是直接和线上维持一致，避免大家bb起来麻烦。

2. 没必要支持timer_service per node了，因为从接口层面来看，只要task_worker_pool有add_timer的接口就行。所以我也直接从node里把timer_service相关的接口删了。

[shengofsun]

将timer per queue内嵌到task queue里面的性能测试也跑了下，基本和之前一样，没啥影响。