2.4.7增加退出位点以及全量并发拉取

2.4.7版本主要增加了2个功能：

1. 用户指定退出的位点，同步推进到这个位点后进程自动退出。
2. 全量增加并发拉取功能。

1. 指定退出的位点

在某些容灾场景下，用户可能结合延迟同步和指定位点退出的功能，实现容灾回滚的需求，例如目的库落后于源库1个小时，中间同步发现出错，回滚到半个小时以前：

1. 源端A同步为5:00，目的端B落后一个小时4:00。
2. 运维同学发现4:30之后的数据不对，需要回滚到4:30。
3. 通过restful接口向MongoShake注入参数："ExitPoint"实现目的：curl -X POST --data '{"ExitPoint": 1593534600}' 127.0.0.1:9100/sentinel/options。此处1593534600为2020年6月30日16:30:00的32位秒级时间戳。
4. MongoShake同步到这个时间点后将会自动退出。
5. 用于将访问流量从源端A切到目的端B。

这相当于是一套容灾+回滚的解决方案。

2. 全量增加并发拉取的功能

2.4.7版本以前，对一个表来说，拉取端的线程只有1个，写入端有多个线程。正常情况这没什么问题，但是一旦用户出现网络延迟大，或者单表倾斜的情况（某几个表特别大，其余表都很小），那么性能就会退化。为了解决这种情况，2.4.7开始提供了full_sync.reader.read_document_count用于并发拉取，那这个配置到底什么意思？
这个参数意味着单个线程能够拉取的最多的文档数，假如用户某个表有50000个文档，而full_sync.reader.read_document_count = 10000，则会启动50000/10000=5个线程进行表切分，然后并发拉取（最小并发是1）。这个值默认0表示仅单线程拉取，大于0的情况会根据上述判断启动多少个线程，有一个额外的约定，当该值大于0的时候，必须也大于等于10000，这是为了用户配置过低导致启动过多的线程数对性能产生影响。建议单表不要启动过多的线程，会对源端mongodb/shake机器/目的端mongodb产生性能影响。
注意，只支持_id主键为同一个类型的情况，比如_id主键又有int，又有string，分片将会丢key。