Improve gradual compaction

[uprendis]

• compaction will try to recursively detect not only upper DB tables but also subtables, based on number of non-empty prefixes in current domain (if number of prefixes (N) > 1 and < 50, then we're probably looking at N tables). Like in previous version (Gradual compaction #384), each detected table is split into S steps (depending on range between first and last keys of the prefix) and compacted
• number of compaction steps is scaled based on total DB size. Total DB size estimation is retrieved via Stat. Having too short steps leads to ineffective compaction for small DBs
• compaction steps are 4x larger for db compact command and debug_chaindbCompact API call
• "nicer" logging during compaction

[hadv]

If I understand correctly when len(nonEmptyPrefixes) >= 50 we will compact the db similar to len(nonEmptyPrefixes) == 1 a.k.a at // once a table is located, split the range into *iters* chunks for compaction . Can you explain a little bit more about it, please?

[uprendis]

It splits it into 3 cases:
== 1:
000001
000002
...
000FFF

It's probably a single table. If keys are numbers, then most likely they all will be behind 00 prefix. An example is epochs storage, which would be behind 00 prefix, because first byte is 0, unless there's more epochs than 2^24

> 1, < 50:
It's probably a collection of tables. An example is gossip DB, which has 34 tables

> 50:
It's probably a single table - that's more prefixes than there's tables in Opera. An example is a collection of transactions or MPTs - both would have 256 non-empty prefixes