RTS-997: Merge with KV to get LevelDB 2.0.15

[hazen]

Probably more than what was needed, but is going to really help the Grand Unification with KV next quarter.

Brian's performance tests don't show any significant changes and TS riak_tests all pass.

riak_ts-develop - 130,026.26 ops/s
eleveldb branch - 134,886.78 ops/s

[erikleitch]

+1

Summary

Mostly straightforward replacement of eleveldb threading with leveldb::HotThreadPool equivalents.

Files details.cpp, mutex.h, threading.h/cc removed because their functionality has been subsumed into leveldb threading code.

eleveldb.cc modified to replace eleveldb thread_pool refs with levelb::HotThreadPool equivalents. refobjects.h/cc modified to extend RefObject from leveldb::RefObjectBase, ErlRefObject and DbObject now use leveldb::Mutex and CondVar classes instead of bare pthread variants.

workitems.cc modified to replace subclassed operator()() with DoWork(), which is now called from a single base-class operator()(), which also wraps notifying the erlang caller of results.

Minor modifications in eleveldb.cc, eleveldb.schema and eleveldb.erl to add cache warming options and atoms.

Comments

• Checked that replacements throughout eleveldb code are functionally equivalent to the old versions. (Note that mutex lock/unlock sequences in refobject.cc have been replaced with instantiation of MutexLock object, which unlocks when it goes out of scope)
• Checked that HotThread::ThreadRoutine() is functionally equivalent to eleveldb::write_thread_worker()

• Performance drop of ~4% noted by @javajolt is probably due to on-the-fly MutexLock/SpinLock construction/destruction in the new workitems/threading code, plus the additional system clock calls in Env::NowMicros() invoked from HotThreadPool::IncWorkWeighted(). Probably not worth troubling about, since much larger improvements will come from rearchitecting data-handling in riak in general.

  I suspect that the performance hit in queries will be even smaller, since there are fewer submissions to the thread pool per-record for queries that return > 1 record, but it would be nice to evaluate that too.