对于binlog dump本身就是阻塞式的读写，使用更简单的BIO

[lcybo]

这个pr会覆盖其他open的pr 536，539。
最近进行的测试，发现了SocketChannel的一些其他问题：
在构建新SocketChannel时，EventLoopGroup调next()就近分配EventLoop进行注册，经过长时间运行，某一个instance的channel如果期间中断过多次，可能round到一个其他instance的channel注册的EventLoop。由于没有在记录log前后设置MDC，日志会记到其他instance的日志文件中。多个channel共享一个EventLoop，轮流使用时间片会使读性能变差（如果消费的快）。

BIO使用较小的SO_TIMEOUT(1s)，处理闪断和interrupt。

其他改动：READ_TIMEOUT_MILLISECONDS修改为(MASTER_HEARTBEAT_PERIOD_SECONDS + 10) * 1000.
+1s的情况，在一个instance无traffic放置一天的测试中，出现了几次读取header timeout，频率大致几小时一次。

[wingerx]

@lcybo 不知 #547 的问题是不是和这个也有关系？

[Wu-Jianqiang]

@lcybo 根据你之前的建议，我对 #536 的修改稍作调整。我觉得异步模式也不错的，读写可以异步进行。 @wingerx 到时候对同步和异步模式分别压测一下试试。最近因为发现还有其它问题，等等再提交。

[lcybo]

@wingerx 谢谢你的测试。请问，当压测停的时候canal的meta里的position和show master status;之间的gap是多少，dump所使用的interface的网络流量情况是什么样的？

[lcybo]

@Wu-Jianqiang BIO和NIO各有优势，各有适用的场景。就MySQL dump来说，在握手成功，订阅指定位置之后，canal单方面接收MySQL的data。“读写可以异步进行”, netty handler里做仅仅是将读到的data‘写入’cache，本质上还是读。对于这样的数量有限（常数）的长连接，我认为还是传统BIO更为适合。如果继续使用Netty，还有一些问题需要解决：
如果多个channel被register到同一个EventLoop（多次中断重新连接，或修改io.netty.eventLoopThreads），多个instance的‘business error’日志会记录到一个instance中，并且一个EventLoop同时处理多个channel，反而影响性能。得实现一个EventExecutorChooser保证一个EventLoop一个Channel。记录Business error时还需要用MDC dispatch.

[agapple]

代码已经合并了，设计上目前暂时都保留了bio和netty，方便做验证和对比