curator 4.2.0
zk 3.4.14
- 等同于zk原生client的会话超时时间。与zk服务端协商后获得最终值（2~20个ticktime范围内），curator默认传60s。心跳间隔或连接断开时间超出该值，客户端、服务端一旦检测到都会主动失效会话。原生客户端readTimeout默认为 2/3个sessionTimeout，连接超时sessionTimeout / 配置的zk节点数。
前者当读数据间隔超过这个时间抛出sessionTimeout（为什么2/3就抛了？看后面），后者是连接的时候好理解:
心跳是最长1/3 sessionTimout时间就会发出一个，或者发送间隔达到10s。所以：
a. 任何对zk的请求都会刷新心跳
b. 静默下一个sessionTimeout内三次心跳
c. 结合4中readTimeout，上次心跳后，到第二次心跳最长是 1/3 sessionTimout，发出后，在等2/3 sessionTimeout服务端没返回，则正好走完一个超时周期，抛出session超时，所以上面是 2/3（代码中写 1-2/3更容易理解）
默认15s 有两个地方用到
- 内部默认等待客户端和zk建立连接的时间。（原生如果失败会一直轮询去连）
background异步操作连接超时后丢弃重试任务用的（题外话，这个异步任务队列是个延迟队列，网络异常配合TreeCache等会有内存积压风险）
如果任务入队已经经过了连接超时个时间，且期间没有和zk连上，重试任务会加入下一次重试或到次数被抛弃（报Background retry gave up）
默认0，ZooKeeper.close(n)时这个n，如果入参0，则进行关闭后不等待，如果入参正数，则会等待zk 收发线程关闭，最大等待时间为该值。
默认1s，curator 退出的时候，等待线程池关闭（内部任务结束）的时间。这个线程池就是给异步任务重试用的。
