The problem of the separation of truncate and append operation about dledger HOT 3 OPEN

@jintianfan Raft 论文中出现 “Figure 8”的场景是因为选举时，日志高度用的是 ComittedIndex，而DLedger 用的是 endIndex（也即当前日志高度，包含所有已经 Committed 的 Entry，可能包含部分未 Committed Entry），详情参考 DLedgerLeaderElector 的 handleVote 方法。
在这种选举标准下， “Figure 8” 中的 S5 是不可能被选为 Leader 的，而一旦一个 Entry 被复制到了 a majority of servers， 则永远不会被覆盖。

from dledger.

@jintianfan Truncate 是在与 当前 Leader 进行比对之后进行操作的。假设选举是可靠的，那么当前 Leader 就包含了所有有效的 Entry，作为 Follower，与当前 Leader 不一致的 Entry 都应该被丢弃，然后与Leader对齐。

from dledger.

@dongeforever 根据endIndex最打选择领导，
假如 一个客户端发起请求请求，三个主机 A (Leader),B(Follower), C（Follower），
Committed 只提交了 A,B ，但是主机C 没有提交，

1 在领导选举，节点B 选择新领导，在同任期情况下，针对此时Committed索引，可以复制到其他节点过充中，
因为是标记commited了，是否还需要继续地业务进行判断

（从客户端角度来说），业务返回成功，还是失败呢？

问题是:对于刚刚标记commited B（只复制A B,C没有请看下），复制到其他节点过（c）中，是否还考虑对业务返回操作成功（发现切换情况下）？
因为标记commited，不清楚是全部写入，还是部分写入

from dledger.