Add status query for total bytes used by a LevelDB instance

[jtuple]

This pull-request adds a new LevelDB property "leveldb.total-bytes" that returns the total bytes used by LevelDB for SSTs. This value is equivalent to the sum of the reported per-level sizes shown in the "leveldb.status" output.

---

The main purpose of this change is for use in Riak through the eleveldb:status API to allow Riak to estimate the total bytes by a LevelDB vnode. The motivation being the new transfer progress work by @jrwest: basho/platform_tasks#23

[jtuple]

Changes will need to be made to riak_kv_eleveldb_backend to expose this value through the new data_size API that @jrwest has created, see: riak_kv/jrw-handoff-progress

Nevertheless, to test this feature as-is, you just need to grab an open LevelDB reference and use eleveldb:status.

To test on a running Riak console:

%% Useful funs to grab LevelDB reference from within running vnode
GS = fun(Pid) ->
             {status, Pid, _Mod, Status} = sys:get_status(Pid),
             Status2 = lists:flatten(Status),
             Status3 = [L || {data, L} <- Status2],
             Status4 = lists:flatten(Status3),
             State = proplists:get_value("StateData", Status4),
             State
     end.

LR = fun(Idx) ->
             {ok, Pid} = riak_core_vnode_manager:get_vnode_pid(Idx, riak_kv_vnode),
             State = GS(Pid),
             ModState = element(4, State),
             case element(3,ModState) of
                 riak_kv_eleveldb_backend ->
                     LvlState = element(4, ModState),
                     element(2, LvlState);
                 _ ->
                     undefined
             end
     end.

%% Use 0 or some other known vnode index...
Ref = LR(0).

eleveldb:status(Ref, <<"leveldb.total-bytes">>).

Result (size in bytes / use list_to_integer to convert to number):

{ok, <<"3373592">>}

[jrwest]

works as advertised.

@jtuple we discussed last week adding in the memtable stats to "total-bytes" in order to preserve the upper-bound on transfer progress. were you going to add that as part of this PR?

[matthewvon]

why a double and not a uint64_t?

[matthewvon]

+1 ... updated code from using double to uint64_t. Executed manual test script from above. All is good.