Testing a protocol in isolation

Protocols are the most important feature of JGroups. They provide the actual functionality in any stack, such as retransmission of lost messages, ordering, flow control, state transfer, fragmentation and so on.

While we do have a sizeable number of unit tests in JGroups, we don't have many tests which test just 1 protocol in isolation.

Take a look at GMS_MergeTest (CVS head), that's how we need to test
protocols in the future. GMS_MergeTest tests (concurrent) merging, and only concurrent merging.

The following features are in this test:

* Injection of views. We inject the subpartitioned views directly
into the cluster, rather than waiting for a failure detector to
kick in. Remember, we test merging and NOT failure detection. The
good thing is that (a) this is much faster and (b) we can really
focus on 1 protocol/feature compared to multiple ones
* Injection of MERGE events. Rather than relying on MERGE2 to (after
some time) generate a MERGE event, we directly inject MERGE events
into the merge leader(s). Same as above: this is much faster and
we don't test MERGE2, but GMS/CoordGmsImpl
* Temporary enabling/disabling of logging for GMS: injectMerge()
enabled TRACE logging for GMS, so we can see what's going on
*selectively*, and don't get a huge TRACE log for the stuff that's
going on before
* SHARED_LOOPBACK: well, I might as well use UDP, but
SHARED_LOOPBACK never loses any messages, therefore no
retransmissions. Again, focus is on testing merging and not
merging with packet loss
* No failure detection, no merge protocol in the stack: this allows
us to set a breakpoint in a debugger and step around for as long
as we want to, without FD suspecting and excluding us

The use of these features allows us to really focus on testing one
feature in isolation. We need to go further into this direction,
thererfore, if you have existing tests you want to modify, go ahead !
New tests should follow this paradigm whenever possible.