A possible improvement over JGRP-2880:

When a view is sent by GMS, it is sent asynchronously as view changes should never block in (e.g. in NAKACK4).

This is a bit cumbersome, because all messages that cannot block, perhaps in other places, need to be identified and need to be changed to send asynchronously.

What if we could handle messages that would block in NAKACK4 directly? If a message is tagged not to block (e.g. DONT_BLOCK), then we can do a few things to comply (ie., not to block the caller):
1. Drop the message
2. Queue the message and send it later, e.g. when the send buffer has space again
3. Use a seperate thread which blocks and unblocks when there is space again

We should certainly not block a message that's tagged as DONT_BLOCK.
Blocking is therefore not an option as we'd change the semantics expected by the caller.

Option #1 is also not feasible for messages that cannot be dropped, e.g. view changes.

Perhaps we need to introduce a new flag with semantics "dont drop but don't block either". This would allow for options #2 and #3, to comply.

Example of using queue:

• A view with flag DONT_BLOCK_DONT_DROP is received by NAKACK4
• The assigned seqno is 22
• The buffer is full
• We queue the message
• 3 messages (sent by separate threads) without the above flag are received, they'll get seqnos 23-25
• Another view with seqno 26 is received, unblocking the send-buffer, and being added to it
• The 3 messages are sent
• The view with seqno 22 is added to the send-buf and sent
  -> Because all views and messages (views are messages) are assigned seqnos, they will be delivered in correct order