lmdb dependency decay

[jacobwhall]

I noticed that osmx-rs depends on this lmdb crate, which hasn't been maintained for a long time. The README for this repo alludes to issues found in lmdb-rs.

Understanding that switching dependencies could require significant effort, are you open to this possibility?

[jake-low]

Yes, definitely open to switching to some other LMDB wrapper. The lmdb crate has some limitations that (I think) make it impossible to implement parallel iteration correctly (there's a long writeup about this in #1 in case you're interested).

I took a stab at porting osmx-rs to using lmdb-zero crate instead, but couldn't get it to work. I just pushed what I have to the experiments/lmdb-zero branch. The branch doesn't build due to lifetime errors; there's some details in the commit message about where I got stuck with this approach.

There are two possible next steps in my mind:

1. Try to port osmx-rs to use heed, yet another Rust wrapper for lmdb. Heed appears to be actively maintained and in use at Meilesearch, so I was hoping it might be more flexible than the crate I'm currently using.
2. Skip the wrapper and refactor osmx-rs to call LMDB directly. This would mean adding some unsafe code to osmx-rs internally (though consumers of osmx-rs wouldn't need to use unsafe), but would mean escaping any limitations that a wrapper crate would impose on the lifetimes of LMDB types. I'm tempted by this option because I think LMDB's API is complex and difficult to map onto Rust's lifetime and ownership rules.