tests: Modified test to use remove-brick instead of 'start' variant

remove-brick start doesn't remove the brick from the volume immediately.
It would wait until migration of data to other bricks are complete. Even
when there is no data to be migrated, one can expect a finite delay from
the time of remove-brick start command's exit and removal of brick(s).
This may cause subsequent checks on brick count to fail in a
non-deterministic manner.

Also, renamed the test file name to reflect bug-id corresponding to
community release.

Change-Id: Ic43f011e251640decb68e46f4a10e0824ade0ac9
BUG: 878004
Signed-off-by: Krishnan Parthasarathi <kparthas@redhat.com>
Reviewed-on: http://review.gluster.org/4885
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
glusterd: Removed 'proactive' failing of volume op

Volume operations were failed 'proactively', on the first disconnect of
a peer that was participating in the transaction.

The reason behind having this kludgey code in the first place was to
'abort' an ongoing volume operation as soon as we perceive the first
disconnect. But the rpc call backs themselves are capable of injecting
appropriate state machine events, which would set things in motion for an
eventual abort of the transaction.

Change-Id: Iad7cb2bd076f22d89a793dfcd08c2d208b39c4be
BUG: 847214
Signed-off-by: Krishnan Parthasarathi <kparthas@redhat.com>
Reviewed-on: http://review.gluster.org/4869
Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>