添加witness副本支持

[lintanghui]

实现方案:

对于witness的实现，核心需要考虑部署方式，对于4+1 的部署方式，实现相对简单，只需要让witness不进行选主，同时同步entry的时候过滤data即可，4+1 部署可以保证即便主节点挂掉依然至少有一个数据副本拥有最新的entry 但是对于2+1 部署 需要考虑的场景相对比较复杂。如果直接和4+1 部署一样的实现的话，那么只要主节点宕机，很容易由于witness拥有最新entry而选不出主， 为了提高可用性，应该允许witness短时间内允许成为主，witness成为主以后在主动transfer leader给另一个副本。

2+1 具体实现为：

• 添加raft_enable_witness_to_leader flag，允许witness临时选举为主
• election_timeout设置为正常节点的两倍，在主节点异常宕机的时候，允许witness发起选主，同时由于election_timeout比数据副本大，可以保证数据副本优先被选为主，主要数据副本延时选主失败时，witness才会主动发起选主
• witness当选为主时，禁止安装快照请求
• 新增witness副本时， witness想leader发送install sanpshot请求，如果replicator本身是witness，则无需进行data文件的复制，只需复制最新的entry即可

[GOGOYAO]

readme文档里面是不是需要补充下说明内容。

[lintanghui]

@PFZheng PTAL

[PFZheng]

witness 可能比任何一个存活的节点数据都要新，代码里是如何控制 truncate，确保数据始终和新 leader 连续的？在 FLAGS_raft_enable_witness_to_leader = false 的情况下，似乎没同步实际数据，怎么保证它不成为主的（靠priority只是降低概率，特别是它的数据确实比其他节点新的时候，可能只有它有资格成为主）

[lintanghui]

witness 可能比任何一个存活的节点数据都要新，代码里是如何控制 truncate，确保数据始终和新 leader 连续的？在 FLAGS_raft_enable_witness_to_leader = false 的情况下，似乎没同步实际数据，怎么保证它不成为主的（靠priority只是降低概率，特别是它的数据确实比其他节点新的时候，可能只有它有资格成为主）

在raft_enable_witness_to_leader 为false的时候，没有初始化vote timer， 此时witness永远不会发起主动选主，witness只是作为一个仲裁者来进行投票，因此也不需要拥有实际的数据

[lintanghui]

@PFZheng any update?

[PFZheng]

见评论，我没其他的意见了