Expanded scope of the handshake locks in SSLHandler 

In certain configurations it seems the handshake lock was released when it shouldn't have been, particularly because functions interacting with the SSLEngine have different behavior when the lock is acquired and when it is not.

We were seeing the case where the first wrap operation was getting to the SSLEngine before our explicit handshake, which would cause either multiple handshakes to be issued, or in very bad cases, and inifnite loop of handshakes. We could only ever replicate this on single processor computers (VM's actually).

These expanded locks fixed our issue.

Also made the handshaking boolean voltatile since it is polled from many threads (a caller of ha ndshake() has no explicit restriction on which thread they must call from)