Properly handle a closed TLS socket with pending receive data.

[jhb]

Summary

If the remote end closes a TLS socket and the socket buffer still
contains not-yet-decrypted TLS records but no decrypted TLS records,
soreceive needs to block or fail with EWOULDBLOCK. Previously it was
trying to return data and dereferencing a NULL pointer.

Test Plan

• reproduced panic during post-commit KTLS testing using openssl s_time
• used a debug printf to ensure the EWOULDBLOCK case was being hit during the s_time test

[jhb]

My original KTLS patchset had some other changes in soreceive_generic() to check for M_NOTREADY that I left out. One of those changes happened to protect against this case (it had added an m != NULL check before the goto dontblock) which is why I never saw this during my pre-commit testing. I chose the immediate goto even though it's a larger patch as I think the meaning is clearer this way (if you have any valid data, always return it) and it also matches the previous block above for so_error. I also chose to put the tlsdcc and tlscc checks under KERN_TLS.