In a heavy cloud storage workflow, I encountered the following error:

```
AssertionError: ctx.bytesavailable > 0 || !(ctx.isreadable)
```
with traces back to calling `eof(::SSLContext)` from `monitor_idle_connection`.

As the workflow was highly concurrent, I believe the error was just a data race
between an old async `monitor_idle_connection` task calling `eof` -> `wait_for_decrypted_data`,
but when returning from `wait_for_decrypted_data` due to a new connection being reused in HTTP.jl,
the `handshake` was redone, which resulted in the `AssertionError` shown above.

The proposal here is that when monitoring idle connections, we only call `eof` on the underlying
TCPSocket, since we're really only concerned with knowing whether the core socket gets additional
data, encrypted or not, when we don't expect it.