In raft, to commit a message, leader firstly broadcasts
MsgApp to replicate data, and once it receives MsgAppResp
from quorum, it
- applies message to state machine
- broadcasts another MsgApp to instruct followers to commit
and these are done in parallel.

To emulate situation where a node is disconnected *after*
config block is committed and *before* node add/remove in
that config block is proposed to raft, `WriteConfigBlock`
stub on leader was overloaded to disconnect node from the
network, so that ConfChange is proposed but dropped.

However this becomes racy when we want to assert the config
block is committed on followers as well, since we might
disconnect leader too fast, and cause the second round of
MsgApp to be dropped, so that config block is not committed
on followers. This is fine in real case because new leader
will continue the effort to commit this block.

To circumvent this flakiness, this CR changes UT to overload
`StepStub` instead of `WriteConfigBlockStub`, so that we can
be more precise on when to disconnect a node from network.

Change-Id: Ic1b7d28c043e779c7cc258c2e08bfaa3578bc429
Signed-off-by: Jay Guo <guojiannan1101@gmail.com>