refactor: handle internal error

[NaughtyDogOfSchrodinger]

check_proposal与commit_block无论结果如何，都会增加块高，导致共识过程卡住，增加判断，只有check_proposal与commit_block均成功，才会增加块高

[rink1969]

fix https://github.com/cita-cloud/consensus_raft/issues/42 fix https://github.com/cita-cloud/consensus_raft/issues/43

[whfuyn]

假设raft的某个包含块100的entry已经committed了，节点A apply了这个entry但它的check或commit没过。如果节点A的块高不增加的话，这时候它成为了leader，找controller又拿了一个块高100的块再propose，它就分叉了。

这边的设计当时讨论了很久，check和commit失败在raft这边是没有合理的解决办法的。最后决定raft这里只保证每个节点都按照确定的顺序提交确定的项，check/commit失败了就让controller自己同步。

如果一直因为高度不对不出块的话，就要看看controller有没有同步上。

[Pencil-Yao]

假设raft的某个包含块100的entry已经committed了，节点A apply了这个entry但它的check或commit没过。如果节点A的块高不增加的话，这时候它成为了leader，找controller又拿了一个块高100的块再propose，它就分叉了。

这边的设计当时讨论了很久，check和commit失败在raft这边是没有合理的解决办法的。最后决定raft这里只保证每个节点都按照确定的顺序提交确定的项，check/commit失败了就让controller自己同步。

如果一直因为高度不对不出块的话，就要看看controller有没有同步上。

实际情况会出现其他微服务的的进程挂掉而导致的check和commit失败 遇到如上情况还有没有合适逻辑去处理， controller目前的角色类似消息的中枢，他从各个微服务获取消息，然后根据拿到的消息结合controller自身信息（由于中枢的身份controller信息~=链信息）判断yes or no传递给其他微服务进行对应的操作，所以我理解的在cita-cloud框架下所有微服务都需要很细的操作细粒度。太过于整体的逻辑在这个框架下很难稳定的运行，加之运行的环境资源切实过于紧张。

[whfuyn]

这个错误是说executor挂掉了吗？这类算是controller里面的逻辑吧，controller不知道怎么处理的话，那consensus的信息更少就更没法处理了。

只能在controller那里想好怎么处理，然后再考虑需要consensus做什么配合。

[Pencil-Yao]

这个错误是说executor挂掉了吗？这类算是controller里面的逻辑吧，controller不知道怎么处理的话，那consensus的信息更少就更没法处理了。

只能在controller那里想好怎么处理，然后再考虑需要consensus做什么配合。

这个问题在于：raft is raft, bft is bft，两者本身就有不同的pattern，正常情况可以找到共性去handle，但出现了问题，对于raft和bft在不同pattern下寻找相同的solution估计是找不到银弹的

[rink1969]

当用户选择raft共识算法时，就意味着没有拜占庭的情况。 因此，commit失败这种其实算是偶发错误，只要多重试几次，最终成功了就可以了，过程中也不会有分叉的情况。

raft这边因为封装的关系，没办法在遇到微服务间调用失败的情况下，通过不投票，或者不进行下一步去让raft驱动重试。 只能是：

1. raft直接往前走，其他微服务稍后再跟上。因为没有拜占庭的情况，短时间的高度不一致也没有关系。
2. 不让raft的高度升上去，可能会导致raft内部状态混乱。

两者相比，还是选择第一种情况比较好。 出问题的场景是因为当时的版本wal的问题（https://github.com/cita-cloud/cloud-util/pull/6）还没有解决。 使用最新版本应该就不会有这样的问题了。