Support read-triggered compactions in RocksDB

### Expected behavior
If an application is incurring a high number of lookups in multiple levels of the SST tree, then it is better to compact that part of the tree so that future lookups do not incur this cost. Compactions triggered by reads would help reduce cpu costs as well as storage iops and storage size cost for these applications.

### Actual behavior
In today's behaviour, suppose the same set of key-range reside in every level of a 7 level SST tree and suppose that no new writes to this key range are occuring. No compactions occurs. And every read request has to look through all the 7 levels of the data to return results.

The cost of lookup is reduced somewhat in the presence of bloom filters, but even then, the cost of cpu to find the key in every one of the 7 individual trees is high.

### Steps to reproduce the behavior