DIRMINA-1173

[jon-valliere]

Implements a Non Blocking Handler for SSL.

The new Handler implements 3 locks and additional queues for guaranteeing order of execution once the locks are released.

• Read and Write operations are still primarily locked on each other. However, each operation now has a Queue for which to deposit produced objects. The Read operation is special in that it can cause Write operations which in turn cause Objects to be placed in both the Read and Write outbound queues. To keep this as simple as possible, this is the reason why they block on each other.
• New Message Receive Queue; the output of the Read operation is a queue containing the Objects which need to be sent to the next filter via the messageReceived operation. The code which pulls objects out of this Queue is blocked by itself so no two threads can be pulling from the Queue concurrently. This design is NOT because ConcurrentLinkedQueues are unsafe in guaranteeing FIFO, its because existing applications may expect a more linear style lock handling versus having multiple threads operate on the FilterChain simultaneously and this could expose bugs which were not there previously.
• New Message Write Queue, the output of the Write operation is a queue containing the Objects which will need to be send to the previous filter via the filterWrite operation. Otherwise essentially the same in function as the Receive Queue.
• The Receive and Write Queues will NOT block on each other.
• The main entry points into the Handler have been wrapped by try..catch blocks to ensure that the Queues can be released regardless of any errors that may have occurred.