return more data at once from TlsStream::poll_read

[trinity-1686a]

When using Hyper with tokio-rustls, and streaming a response body, hyper only emits blocks of 16k (a single TLS record), even when hyper uses a larger receive buffer. This causes more wake-ups for hyper callers, and generally more work inside hyper itself.

This PR makes it so TlsStream::poll_read tries to return more data at once, which measurably improves Hyper's performance over TLS streams.

I assume there is a similar gain on the server side with requests that have a large body (instead of response having a body for client), though i haven't attempted to measure or fix that yet.

very simple (but noisy) bench setup:
running a slightly simplified version of this example (commenting out to_bytes() and actual printing of the body, to make the gain more visible), and running perf stat ./target/release/examples/client https://proof.ovh.net/files/1Gb.dat (download 1GiB from a remote server), i get

cpu-cycles:u
before: 3.6B
after: 2.7B

task-clock:u
before: 11.7s
after: 7.3s

While this could also be a change in hyper to call poll_read() until it returns Pending, i think other consumers of rustls could have the same inefficiency, and this is better handled at that level.

[djc]

LGTM, thanks!

[djc]

Nit: suggest flipping this with an early return, to reduce rightward drift.

[djc]

Nit: using a symmetric min() like Ord::min() makes this easier to follow IMO.

[djc]

Would be cool to also do this for the server side.

[trinity-1686a]

i've confirmed the effect on the read path of the server.

i should also add because it bite me while trying to assess performance on the server half that, in hyper, this only impacts http1, h2 there seem to use much smaller buffers so that results are largely within the variance of my setup