Fix last_applied failing assertion

[freeekanayaka]

This fixes #355, see the reproducing test and commit messages for details.

[codecov]

Codecov Report

Merging #423 (d144504) into master (7cfccd3) will decrease coverage by 0.01%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master     #423      +/-   ##
==========================================
- Coverage   76.64%   76.64%   -0.01%     
==========================================
  Files          50       50              
  Lines        9571     9573       +2     
  Branches     2439     2441       +2     
==========================================
+ Hits         7336     7337       +1     
  Misses       1162     1162              
- Partials     1073     1074       +1     

Impacted Files	Coverage Δ
src/replication.c	69.15% <66.66%> (-0.05%)	⬇️

[freeekanayaka]

Note that this fix is probably a bit too brute force, as I believe there's no reason to not allow followers to have their last_stored index lag behind their commit_index, pretty much like leaders do already: as soon as they receive from a leader a commit_index that they already have appended to their in-memory log, it's safe for the follower to increase its commit_index and apply it to the FSM, even if that entry is still being persisted. That entry could also then fail to be persisted and that would be fine too, because the FSM has applied a committed entry, albeit not yet persisted locally (again, exactly like leaders already do). We acknowledge to leaders only persisted entries, which is what counts for commitment, and that's unrelated to what we've applied to the FSM.

However I'd keep implementing the above as a possible follow-up improvement.