AddPeer may be failed and some problem resulted by this.
使 Timer 的运行独立于 timer 的锁，否则很有可能造成死锁
 add an new error text
 fixbug

descript: 当发送请求之后在发送取消请求，在 RpcClientChannel
的 hanling_ 当中，与一个 ClientSession 对应的 id 有两个，
请求的 RequestID 和 取消的 RequestID. 如果此时发生链接断开的情况，
RpcClientChannel::CleanupRequests 将会被调用。这类的请求将会被调用
两次。

方法1
在 ClientSession 当中增加一个是否清理的标志位，如果清理过了则不再清理。
直接操作 RpcClientChannel 是不太明智的选择，因为第二次出现 RpcClientChannel
的时候， 有可能对应请求的 done 函数已经被调用了，访问 Request, Response,
Controller 都是不安全的操作。而ClientSession 使用 std::shared_ptr 管理，
只要有引用，访问他就是安全的。

方法2
RpcClientChannel 增加一个单独的 ClientSession, RpcClientController 记录
了 RequestID 和 CanncelRequestID, 当他们当中任意一个完成的时候，直接取消
他们两个就好。这个方法有个坏处就是完成的时候，需要操作 handling_, 而
Cleanup 时的嵌套调用也会出现问题 (此时正在进行 handling_ 的枚举)。此外，
无论是”正常请求“还是“取消请求”， 他们完成时的处理都更复杂一些。

方法3
如果请求类型是 Cancel, 则不再 Cleanup 的时候清理，直接跳过即可。这种方法
的麻烦之处在于目前没有方法记录那个 RequestID 用来做的 cancel request