switch lmdb-rs dependency to mozilla/lmdb-rs fork (fix #70)

[mykmelez]

Per #70, we should switch from the crates.io package to the mozilla/lmdb-rs fork of the lmdb crate, where we've taken fixes for rkv.

I'd rather not publish mozilla/lmdb-rs to a new crates.io package, which'd require a different (but presumably similar) name, sow confusion about the differences between the two crates, and potentially complicate unforking in the future.

Instead, I'd like to point rkv's lmdb dependency to mozilla/lmdb-rs via its Cargo.toml file's [dependencies] section, which is a paved cow path, f.e. in https://searchfox.org/mozilla-central/source/gfx/wrench/Cargo.toml, where Gecko does that for yaml-rust and osmesa-src.

Another option would be to override rkv's lmdb dependency via a patch, as https://searchfox.org/mozilla-central/source/Cargo.toml does for serde_derive. That could avoid depending on two incompatible versions of the crate, as described in rust-lang-deprecated/failure#230 (comment) and following comments. But I don't think that's an issue in this case, as I don't expect Gecko's crate dependency tree to include another dependency on lmdb.

Thus I think the best option is for rkv to depend on mozilla/lmdb-rs via its Cargo.toml file's [dependencies] section, and that's what I've done in this branch.

I've further specified that rkv should depend on the "rkv" branch of mozilla/lmdb-rs, to ensure we're explicit about upgrading the dependency. (Otherwise, any change to mozilla/lmdb-rs's master branch would implicitly upgrade the dependency, which feels brittle.)

@ncalexan I'm requesting review from you at an architectural level, not a code level (as the code changes are trivial), to get a sanity check on this plan!

[ncalexan]

My only comment is that you can pin to a SHA, if you choose to. Otherwise, I agree: don't try to push to crates.io right now; don't use the dependency-override mechanism, which isn't needed (yet).

[mykmelez]

My only comment is that you can pin to a SHA, if you choose to.

Indeed. That too would require an explicit step to upgrade the dependency, and the step would be on the rkv side rather than the lmdb side.

I'm unsure if that's better than pinning to a branch, which gives us some flexibility to upgrade the dependency on the lmdb side in a non-breaking fashion, i.e. the equivalent of a crates.io package incrementing the "patch" part of its semver version number.

I'll stick with the branch approach for now but continue to evaluate the relative benefits (and perhaps also get feedback from Gecko peers during review of the vendoring patch).

Otherwise, I agree: don't try to push to crates.io right now; don't use the dependency-override mechanism, which isn't needed (yet).

Woot, thanks for the input!