As discussed in #153, CursorIterator does not reflect the usual Java iterator idiom where an Iterable is able to produce multiple Iterator instances. This restriction exists because LMDB is used to provide the elements through an underlying transaction (provided at the time Dbi.iterate(..) is invoked) and cursor. Due to the use of these native resources, it is impractical to effectively produce multiple arbitrary Iterators from the same Iterable, especially given each Iterator would need to be individually AutoCloseable to release its associated LMDB cursor.

It is difficult to envisage a practical use case for reusing an Iterable in the first place, especially given the shared Txn and KeyRange would result in the same the data for all returned Iterators anyway. Furthermore users with advanced needs are referred to Dbi.openCursor(..), as this permits moving the cursor in any direction and at any time while the Txn remains available.

While #153 added a simple guard to prevent acquiring multiple Iterator instances, the overall design remains non-idiomatic. Fundamentally Dbi.iterate(..) should return a class that implements Iterable so that the returned object can be directly and idiomatically used in an enhanced for statement. This would mean:

• Renaming CursorIterator to CursorIterable
• Implementing the Iterable interface on CursorIterable
• Removing the Iterator interface from CursorIterable
• Relocating the Iterator methods into the inner class returned from CursorIterable.iterator()

Unfortunately these changes represent a minor breaking change for existing users. Given this is a breaking change, it's a good opportunity to remove the deprecated IteratorType as well. The IteratorType was deprecated in LmdbJava 0.6.0 (released July 2017) and represents the only deprecated code currently remaining in LmdbJava.