Ignore clientNastyClose test on multithreaded SSL scenarios for now
Implement getEngine for new SSL connection
Prevent runaway read/write listeners in SSL
Break infinite loop that happens when we receive CLOSED with NEED_UNWRAP (on unwrap).

Before, this would lead to unwrap and unwrap and unwrap, endlessly. Now, we try to read data from underlying conduit.
If there is data, fine, we unwrap again, if there is none, there is no alternative but to return (the lack of alternatives
comes from the ssl engine insisting in unwrapping where there is no data to unwrap).
At JsseStreamConduit.performIO, treat the scenario where flush->wrap received a closed channel.

This happens when the client is still flushing but has received a close message from the other end
Code cleanup