修复主从同步过程中的一些问题

[cheniujh]

经过梳理和测试发现：

• 第一类问题：一次性要对多个key进行写操作的命令，其binlog可能无法在从节点正确消费（关联 pika commands that write to multiple keys in a single operation may cause inconsistencies between the master and slave nodes due to improper binlog handling #1638

  涉及命令（通过测试也发现确实有主从同步问题）：
  1. Del
  2. Mset
  3. Msetnx
  4. Smove
  注：Rpoplpush也有该问题，但是之前已经提了pr进行修复

  修复措施：（都是重载了Dobinlog方法来拆分了binlog）
  1.Del多个key时，将binlog拆成多条单key的binlog
  2.Mset多个key时，拆成了多个Set单key的binlog
  3.Msetnx多个key时，拆成了多个Set单key的binlog
  4.Smove拆成了一条Srem加一条Sadd的binlog

  修复结果：测试均能稳定通过，问题应该解决了

• 第二类问题：请见下图

 确实测试出了主从不一致的命令：
         1.bitop
         2.pfmerge
实际测试中没有出现不一致问题的命令（集合相关的这批命令）：
         1.sdiffstore
         2.sinterstore
         3.sunionstore
         4.zunionstore
         5.zinterstore

目前关于bitop和pfmerge的修复：思路是直接把master的运算结果给slave，省的它再次计算
首先：Pika的hyperlog和bitmap结构都是基于String的（比如bitmap，实际上就是对一个string做位操作，hyperlog类似, 但是hyperlog是基于一个128KB的String）
bitop命令：binlog改成了一条set的binlog，写成了 ：set key result_to_dest （注： result_to_dest就是后面使用后面两个key得到的运算结果，也就是存到了第一个key中的内容
pfmerge命令：类似于bitop，我把binlog改成了一条set，将修改后的结果直接set过去

 修复结果：测试均能稳定通过，pfmerge,和bitop命令的主从同步问题能这样解决

我需要求助的地方在于：

1.hyperlog结构基于一个128KB定长的String，如果把pfmerge的binlog改成一条set，那每次执行pfmerge就会产生一条长度128KB的binlog，虽然跑了比较久的测试都稳定，但是128KB的单条binlog会不会引起什么其他问题？

2.上面关于集合的这批命令，分明在逻辑上是会有主从不一致问题的（和bitop,pfmerge一样原因），甚至他们在storage层都没有锁任何的key（没有重写Cmd::current_key方法),但是为什么他们却没有测试出主从问题？
补充：最新测试结果，sunionstore测试出了一次不一致，所以总的来说，应该说集合的这批命令也会有主从问题，只是概率比较低
（storage层给key加锁以后，似乎就没问题了）

我注意到这些集合命令在DB层面操作操作时，都会使用rocksdb的snapshot
所以我尝试也给pfmerge在DB层基于snapshot来操作（就不用写一条128KB的binlog了），但是修改以后pfmerge依旧有一致性错误，是我改的不对嘛（也烦请大家帮忙看一下pr中pfmerge对应的修改，看看我是否正确地使用了snapshot）？
还是说这些集合命令一致性的保证并不是依赖于snapshot机制的？