with the previous value we basically did sync reading which means that
network and cyrptographic overhead head a huge impact on throughput.
meanwhile the perfect way to use asyncness is to schedule a whole bunch of
requests before starting to read.
previously this was documented as auto-adjusting, which it never was,
there's also little to be gained from adjusting this value on the fly.
more requests in most scenarios will simply mean a larger RAM footprint as
more data potentially sits in libssh waiting to be read. with 128 requests
that'd be ~8mb (assuming the file transferred is that large)

this improves read performance with libssh 0.8 by up to 20 times for large
files. read performance with libssh 0.6 is 2 to 3 times better.
the faster the connection the higher the gain of course.

128 gives somewhat competitive performance results compared to openssh's
ssh implementations while not having too large a footprint.

in raw numbers: a local link read was averaging around 10mb/s on both
libssh versions. with 128 requests this goes up to 200. competitive is
between 200 and 300 it seems (obviously all specific to my system)

CHANGELOG: sftp file reading is now up to 20 times faster