FAB-15939 Fix Raft flake

Makes a Raft UT more lenient to fix flake. The flake happens
when leader initiate leadership transfer too fast, that follower
hasn't applied reconfig yet. In this case, follower will eventually
be able to claim leadership after election timeout. Instead of
asserting intermediate procedures, we could simply assert the final
result - after certainly amount of ticks, the only remaining node
in cluster will be able to elect itself.

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

Author: guoger

orderer/consensus/etcdraft/chain_test.go

@@ -1347,16 +1347,15 @@ var _ = Describe("Chain", func() {
 		It("can remove leader by reconfiguring cluster", func() {
 			network.elect(1)
 
-			n := c1.clock.WatcherCount()
-
 			By("Configuring cluster to remove node")
 			Expect(c1.Configure(configEnv, 0)).To(Succeed())
 			Eventually(c2.support.WriteConfigBlockCallCount, LongEventualTimeout).Should(Equal(1))
-			Eventually(c2.configurator.ConfigureCallCount, LongEventualTimeout).Should(Equal(2))
+			c1.clock.WaitForNWatchersAndIncrement(ELECTION_TICK*interval, 2)
 
-			c1.clock.WaitForNWatchersAndIncrement(time.Duration(ELECTION_TICK)*interval, n+1)
-			Eventually(c1.Chain.Errored, LongEventualTimeout).Should(BeClosed())
-			close(c1.stopped) // mark c1 stopped in network
+			Eventually(func() <-chan raft.SoftState {
+				c2.clock.Increment(interval)
+				return c2.observe
+			}, LongEventualTimeout).Should(Receive(StateEqual(2, raft.StateLeader)))
 
 			By("Asserting leader can still serve requests as single-node cluster")
 			c2.cutter.CutNext = true