Flexible MultiRead demonstration

[archang19]

We want to enable FilePrefetchBuffer to make read requests that are block aligned whenever possible. This means rounding up the read requests to the next block boundary.

There are quite a few different options we can go down, and I have written some analysis on their tradeoffs.

Working through a sample prototype / hacky implementation can make the decision more obvious, and in this case I think that was very true.

It looks like the "flexible reads" approach is the most attractive. However, we will be using the MultiRead API, rather than the Read API, since we want to take advantage of the file system buffer reuse optimization, which only MultiRead supports currently. We can easily add new fields to FSReadRequest to support our use case, while maintaining backwards compatibility.

I really think that our final approach can be very, very simple. I put one approach in this PR where we only need to:

1. Expose the block size in FSRandomAccessFile and RandomAccessFileReader
2. Add a new field inside FSReadRequest
3. Adjust the rate limiting logic to take into account the potential additional readahead

Minor decisions to be made:

1. Whether to add a new option inside IOOptions to gate the feature. Right now we can just rely on for_compaction which is given to us in TryReadFromCache. In the future we want to expand this to low-priority reads, but right now IOOptions's priority field is marked as deprecated.
2. Whether we can even get away without adding a new block size interface to FSRandomAccessFile / RandomAccessFileReader. We still would want to specify some max read size for rate limiting purposes, but this option may work if we allow more flexibility into how much more data can be returned. As long as our max readahead size covers the block boundary, we would benefit from the optimization. Personally I don't think adding the block size interface is too bad, since it is a somewhat general concept.

I think this approach is very promising. We can hide almost all of the complexity on the RocksDB end, maintain backwards compatibility / safety, and still make the optimally sized read requests.