Support to use row cache of RocksDB

[ShooterIT]

For kvrocks point lookups, row cache is more useful than block cache, so we can enlarge row cache size and lessen meta/subkey block cache size.

If there are some hot keys that have the same prefix, they may be in the same block cache, so competition will be more serious, but if we use row cache, these keys may distribute into different cache shard since in row cache, distribute them by its hash value.

"4G block cache" VS "2G row cache and 2G block cache"

Test by benchmark (-t get -d 1024 -r 10000000 -n 10000000 --threads 8 -c 128)

Use row cache	First test	Second test	Third test
No	291358	275755	242318
Yes	266084	263067	270182

in random mode, there is no obvious difference.

[caipengbo]

Meta data is mostly a point-query scenario, subkey is often a range query. Can we use only row cache in meta and only block cache in subkey?

[ShooterIT]

I don't find a solution now, row cache is a global cache.

[caipengbo]

LGTM, just a minor problem about config comments.

[ShooterIT]

Currently, from my some tests, i don't find row cache has obvious profit. Now i convert it to draft, maybe i have wrong understanding, if anyone have new ideas, happy to listen your thoughts

[git-hulk]

LGTM

[ShooterIT]

If there are some hot keys that have the same prefix, they may be in the same block cache, so competition will be more serious, but if we use row cache, these keys may distribute into different cache shard since in row cache, distribute them by its hash value.

And in theory, row_cache is more useful for hots keys scenario since we don't need search on index and data block.

But this mechanism is not always useful and also use more memory, so we disable it by default, you can enable it if you want to test or use it.