os: KeyValueDB: expose interface to obtain estimated store size

On LevelDBStore, instead of using leveldb's GetApproximateSizes() function,
we will instead assess what's the store's raw size from the contents of
the store dir (this means .sst's, .log's, etc).  The reason behind this
approach is that GetApproximateSizes() would expect us to provide a range
of keys for which to obtain an approximate size; on the other hand, what we
really want is to obtain the size of the store -- not the size of the
data (besides, with the compaction issues we've been seeing, we wonder
how reliable such approximation would be).

Signed-off-by: Joao Eduardo Luis <jecluis@gmail.com>
test: ceph_test_store_tool: output estimated store size on 'get-size'

Signed-off-by: Joao Eduardo Luis <jecluis@gmail.com>
mon: MonitorDBStore: rely on backing store to provide estimated store size

Signed-off-by: Joao Eduardo Luis <jecluis@gmail.com>
mon: mon_types: DataStats: add 'dump(Formatter*)' method

... and use it on DataHealthService.cc, instead of building our own
version of the classes' formatted output.

Signed-off-by: Joao Eduardo Luis <jecluis@gmail.com>
mon: DataHealthService: monitor backing store's size and report it

If the store's size grows beyond what we believe to be reasonable, we must
let the user know that something fishy may be going on.  This intends to
act as an early warning system for monitors suffering from leveldb
compaction issues.  However, if the monitor's store is just growing a lot
due to normal cluster behaviour, we made sure that the warning threshold
is adjustable by tuning 'mon_leveldb_size_warn' (defaulting to 40GB).

Fixes: #5909

Signed-off-by: Joao Eduardo Luis <jecluis@gmail.com>