iterate_upper_bound semantics/performance opportunities

I should have probably looked at the actual implementation, but if `rocksdb::ReadOptions::iterate_upper_bound` is defined, then maybe, when iterating, instead of comparing each key against the prefix key provided in Seek(), the upper bound can be used to determine, well, the upper bound using e.g binary search, so that you can safely assume that within a range [start, end) all keys will be >= prefix and thus commit the comparison altogether.
Apologies if this is already the case -- it doesn't seem to be though.