Switch to rust-rocksdb in kvdb-rocksdb

[bkchr]

kvdb-rocksdb currently uses our own fork of rust-rocksdb. The fork is diverged quite a bit. We should switch back to upstream, to get the latest updates. I started doing this in: 616b401

There are some TODOs on what is missing. We also need to upstream some functionality from our fork to upstream.

[dvdplm]

Do you think the kvdb-rocksdb test coverage is adequate or is this a good time to improve on that?

[bkchr]

I did not even know that there are tests 😅
There are not that much tests, but I think that a benchmark would be good to have. So that we can compare with and without switching to rust-rocksdb.
It would also nice to have at least compile tests for windows and Android, so that we know that we at least can compile for these platforms.

[tomtau]

btw, here's a bounty on this issue: https://www.bountysource.com/issues/67028819-switch-to-rust-rocksdb-in-kvdb-rocksdb

[ordian]

I've taken a look at this issue (in ao-upstream-rocksdb branch, only this commit 90b47c1) and the following things are lacking in the upstream:

• ColumnFamily (Column in paritytech's fork) is not Copy and even lock-free (Make cf_handle lock-free rust-rocksdb/rust-rocksdb#279), this might incur significant perf overhead for transactions.
• Several options.set_... methods are missing (see todos in 90b47c1, also cc Options, ReadOptions, WriteOptions missing many settings rust-rocksdb/rust-rocksdb#260).
• Several methods take Options by value (e.g. DB::repair), instead of by ref, which is not clonable.

[dvdplm]

We also need to upstream some functionality from our fork to upstream.

@bkchr can you elaborate a bit on what it is that is missing upstream (other than the differences @ordian mentions)?

[bkchr]

I think the list of @ordian seems to be correct.