benchmark: rocksdb concurrent reads/writes

[unnawut]

Opening this PR just for reference so we can copy & paste to do more benchmarking in the future.

This is done on my local machine so the numbers are much lower than what we're seeing on deployed environments. But some findings:

1. Rocksdb reads and writes do interleave. But we route through OMG.DB.RocksDB.Server which handles one message at a time and so is probably the reason why our read/write operations are blocking.
   • Implement read/write as async tasks into this GenServer?
   • Reads could also be turned into a stream I think.
2. Within OMG.DB.utxos(), the read iterator and decoder takes most of the time. The decoder takes most of the memory.
   • Can try optimize on the iterator to optimize for time. Decoding could be a stream to optimize for memory
3. Tried rocksdb snapshots, with or without, doesn't significantly impact concurrent reads/writes (see results)
   • Ignore rocksdb snapshots for now
4. Doesn't look like any caller needs the reversed utxo list this would shave off a few milliseconds

[unnawut]

Not intending to merge this but want to keep the files for the record.