Review Board 1.7.22

[HBASE-4496] Caching blocks in seekBefore and refactoring HFile reader access in HFileBlockIndex

Review Request #2136 - Created Sept. 30, 2011 and updated

Mikhail Bautin
jgray, lhofhansl
This fixes a couple of long-existing code issues in HFile v2:
- Making seekBefore cache the previous block it has to read when the scanner happens to be at the first key of a block (this was a performance regression introduced in HFile v2).
- Fixing the accounting of the number of blocks read for the one-level index case in HFileBlockIndex.seekToDataBlock if the current block is the same as the requested block.
- Getting rid of HFileBlock.BasicReader, which was used both by FSReaderV2 and HFileReaderV2, but the former did not cache blocks (a source of confusion).
- Adding a new interface HFile.CachingBlockReader instead, which is implemented by HFile readers and passed to HFileBlockIndex.
This is in production in Facebook's hbase-89 branch. 

Still testing this open-source patch -- please don't commit yet.
Review request changed
Updated (Oct. 2, 2011, 9:58 p.m.)
Fixing comment to be consistent with the expected number of blocks in code.