On Linux this significantly increases gcsfuse sequential read throughput.

As best I can tell, this instructs the kernel not to synchronize on the
completion of a read request before sending further requests. This
definitely means further read requests, but I believe it means any sort
of request as well. It appears to make a big difference to gcsfuse read
support.

It's too confusing with a distinct set of IDs for logging.

This adds up to a significant performance gain for gcsfuse, in its sequential
read benchmark.

Also ReadDirOp.

In preparation for allocating them up-front for ReadFile and ReadDir.

The new API lends itself toward reading directly into the output buffer, saving
a memmove and allowing for easy reuse of output buffers.

This eliminates about half of the allocations by bytes for gcsfuse's sequential
read benchmark.