Fixed empty and leastSize for OpenSSLStream

[machindertech]

The previous implementations were sometimes incorrect, because
SSL_pending only returns the current pending bytes without blocking, and
even if the underlying stream has data available, it might not be
application bytes. Using SSL_peek will block until application
bytes are available or the end of stream has been reached.
See http://permalink.gmane.org/gmane.comp.encryption.openssl.user/6536

[tosttost]

maybe related, maybe OT: I have trouble with a vibe.d https server. More precisely, a POST file upload to a server running on AWS.

With some OS/browser/connection combinations, the server logs
"Reading from TLS stream was unsuccessful with ret 0" from openssl.d line 279 and the browser gets no response.
If one combination fails, it fails reproducible. For some unknown reason, connecting to a VPN can fix it. After disconnecting from the VPN, the error occures again.

I tried this PR and exept the log line is now triggered in line 280 nothing changed.

[tosttost]

It turned out that vibe.d is not to blame for the "Reading from TLS stream was unsuccessful with ret 0" errors we experienced. In fact no POST request with sufficient large body did not made it to the server (EC2 instance). We tried a clean instance and different favours of gnu/linux as well as a variant of python's SimpleHTTPServer... A "first usage of wireshark" investigation seemed to indicate that the request arrived crippled inside the instance (reason unknown).
After switching to another provider, everthing works fine.

[s-ludwig]

Sorry for letting this sit here for so long! I somehow associated this with a very obscure solution, but apparently that was another PR for the same bug. This one makes a lot of sense on the other hand. I've cherry picked the change to master as ee35d73.