support arbiter in a new way

[CkTD]

支持 arbiter 副本，arbiter 不维护 FSM，没有用户数据，不能成为主，只能发起投票，必要时协助日志提交。

实现方式

• 如果group能通过非arbiter节点提交日志，leader 停止向 arbiter 副本复制任何日志（此时 arbiter 副本等价于长时间落后的节点）。
• 如果发现group无法通过非arbiter节点提交日志，group 进入降级模式，leader 重新开始向 arbiter 副本复制日志的元数据 （此时 arbiter 副本帮助提交写请求）。
• leader 需要开始复制日志到 arbiter 上时，总是先安装一个特殊的快照，让 arbiter 快速catch up。这个快照是 leader 临时构造的，只包含元数据，由最新的日志 id 和 conf 构成。

分析
一致性：引入arbiter不会影响一致性。
可用性：引入arbiter会降低可用性。考虑以下场景： 3个节点，时刻A ，挂了一个非arbiter节点，此时 leader 通过arbiter提交一些日志。时刻B，旧的leader 挂了，并且挂掉的非arbiter节点恢复。恢复的节点无法成为主，因为缺失了一些日志，会被 arbiter 节点拒绝。这个是可以接受的，因为故障出现了交集，概率非常小。

对比其他实现

优点：

1. 正常情况下，leader 与 arbiter 之间只有心跳，开销比较小，可能有助于增加 qps。
2. 不会出现leader挂了，arbiter日志可能更新的问题。

缺点：

1. 写请求时延可能增大（例如，3副本，其中一个为arbiter，正常情况下leader 必须把日志复制到非arbiter follower节点上才提交， 而不是两个follower中的任意一个）。
2. 如果非 arbiter follower 故障，检测到降级之前，无法提交新日志。

总结：这个方案可以减少空间占用、提高qps，但会增加 latency，降低可用性。