Fix NAKACK unit test

The pbcast.NAKACK protocol provides reliable transmission of multicast messages in a group, guaranteeing that for each receiver, all messages received from a given remote peer will be FIFO ordered.

The NakAckTest makes use of the ProtocolTester class to test pbcast.NAKACK while sandwiched between two Protocol layers: a test harness protocol layer , used to send messages into and receive messages from pbcast.NAKACK, and a LOOPBACK layer used as transport.

This test has a couple of problems at the moment:
the test simulates the sending of messages from one peer only, thus not adequately testing the peer by peer FIFO ordering property ;
(ii) the logic used to check the correct FIFO ordering of messages works for the case of one peer but will break in the case of multiple peers

For the correctness check, instead of checking that, for each peer, the sequence number received from that peer is one greater than the previous
sequence number received from that peer, it compares the sequence number received from any peer against a single value called highest_seqno -
effectively checking that when messages arrive from peers, they are totally ordered. This is too strong a guarantee and should be changed.

I've also noticed that we have two mechanisms for testing protocols in isolation: ProtocolTester and Simulator. I assume that ProtocolTester is a precursor to Simulator. Was the use of ProtocolTester the reason why
only one peer was used? Should this test also be converted to use Simulator? As described in the wiki (http://wiki.jboss.org/wiki/JGroupsSimulator) there is lots of potential for using Simulator to model failures at the transport level, which would improve the unit testing of protocols.

Comments from Bela:

We should get rid of one of the two (probably ProtocolTester, as you said), and focus on building out the other.

Yes, looks like that test is flawed. +1 on creating the JIRA issue, which should fix the test code, and possibly port it to Simulator from ProtocolTester.

Yes, the idea was to use Simulator as a way of sandwiching one or more protocols between Simulator and LOOPBACK (might be a good chance to see if we can trash that one too, and use SHARED_LOOPBACK instead !), inject a number of inputs (ie. messages) and compare the output to expected output.