The update to rustls-ffi 0.8.0 changed handling of EOF and close_notify.
From the CHANGELOG:

> Handling of unclean close and the close_notify TLS alert. Mirroring upstream changes,
> a rustls_connection now tracks TCP closed state like so: rustls_connection_read_tls
> considers a 0-length read from its callback to mean "TCP stream was closed by peer."
> If that happens before the peer sent close_notify, rustls_connection_read will return
> RUSTLS_RESULT_UNEXPECTED_EOF once the available plaintext bytes are exhausted. This is
> useful to protect against truncation attacks. Note:
> some TLS implementations don't send close_notify. If you are already getting length
> information from your protocol (e.g. Content-Length in HTTP) you may choose to
> ignore UNEXPECTED_EOF so long as the number of plaintext bytes was as
> expected.

That means we don't need to check for unclean EOF in `cr_recv()`, because
`process_new_packets()` will give us an error if appropriate.

When we're reading out plaintext from rustls' internal buffers, we might
get a read of zero bytes (meaning a clean TCP close, including
close_notify). However, we shouldn't return immediately when that
happens, since we may have already copied out some plaintext bytes.
Break out of the loop when we get a read of zero bytes, and figure out
which path we're dealing with.