When closing a unicast connection from B to A, and then sending 5 unicast messages from B to A, A might receive more than 5 messages.

Cause:

• B sends a JOIN-REQ or some other unicast (e.g. VIEW-ACK) as part of the join process to A. The connection ID (conn-id) sent here is 0.
• B closes its connection to A
• On sending the 5 messages, B creates a new conn-id (1)
• B receives a few messages with conn-id=1 and delivers them.
• Now B might receive a spurious message with conn_id=0, e.g. a delayed VIEW_ACK.
• Because conn-id=0 != conn-id=1, the {{ReceiverEntry} for B is removed on A and a new one created with conn-id
• When a next message is received with conn-id=1, the entry is yet created again.
• This means that we don't know that the previous messages were aready received, and we receive and deliver them again!

SOLUTION:

• Instead of checking for inequality (!=) between conn-ids, we
  • drop messages with a conn-id < entry.conn-id
  • when a greater conn-id is received, we remove the ReceiverEntry and recreated it with the bigger conn-id

Unit test: UNICAST_OOB_Test.testSecondMessageReceivedFirstOOBBatched().