raft: add lastIndex as rejectHint

Fix #1995 #2002

This commit tries to solve the problem that a leader tries to decrease the next index of a follower that has a huge index gap. For example, a newly elected leader resets all the followers' next to 10,000. However, the follower A only has 10 log entries due to long time failure. The leader needs to do more than 9K RPC to decrease the next to 11 to match with A.

In the raft paper:
> If desired, the protocol can be optimized to reduce the number of rejected AppendEntries RPCs. For example, when rejecting an AppendEntries request, the follower ￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼￼can include the term of the conflicting entry and the first index it stores for that term. With this information, the leader can decrement nextIndex to bypass all of the conflicting entries in that term; one AppendEntries RPC will be required for each term with conflicting entries, rather than one RPC per entry. In practice, we doubt this optimization is necessary, since failures happen infrequently and it is unlikely that there will be many inconsistent entries.


I do not use this approach since I have the similar opinion with the author that `failures happen infrequently and it is unlikely that there will be many inconsistent entries.`. 

The approach described above tries to remove the actual conflicting log entries. Conflicting log entries can only be created with two concurrent leaders, one is a previous leader(it does not aware of the new leader) and the other one is the current leader. 

This does not happen a lot in practice. Also, I think a better solution is that the previous leader should step-down and remove all the log entries that no follower has matched for that term.

/cc @ongardie @bdarnell
rejected, last uint64