Prefix extractor and ordered iteration, and non-blocking semantics

According to this [wiki page](https://github.com/facebook/rocksdb/wiki/Prefix-Seek-API-Changes)
> When options.prefix_extractor is not nullptr, iterators are not guaranteed a total order of all keys, but only keys for the same prefix.

According to the [tuning guide](https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide)
> RocksDB keeps all data sorted and supports ordered iteration. However, some applications don't need the keys to be fully sorted. **They are only interested in ordering keys with a common prefix.**

For most of the datasets I am managing, being able to extract the prefix and build the per-SSTable bloom filter by using that prefix(as opposed to the whole key) is very important, for it can be used to skip SSTables when iterating KVs.

However, it's not clear to me what it means this means in practice for iteration semantics.
- Does it mean that when the memtable is flushed, only the prefix is considered (i.e the KVs are sorted by the key prefix, and not by whole key?). This doesn't seem to be the case because custom comparators operate on whole keys and I don't see how this would work otherwise(unless you are expected to check the keys to be compared to determine if they are whole keys or prefixes)?
- Does it mean that when iterating and the start key size if shorter than the size of the prefix extracted the KVs may be returned out of order?
- Does it mean that when iterating, and the prefix is extracted from the seek key, all returned KVs may be out of order?
- Does it mean that if keys are put() out of order, they may be returned in that order during iteration?

For some datasets, it's important that KVs are returned in their natural order (e.g if the key encodes a tuple of integers, and the last member of the tuple encodes a timestamp, where I want to process those keys in ascending order of all tuple members), for some other datasets I don't mind if they are retrieved out of order.

I 've been experimenting with this for a while, and KVs are always returned in the right order. I am just curious when they could be returned out of order, and if when memtales are flushed to SSTables keys are always sorted in the correct order(based on the comperator) regardless of the prefix.

---

I am also curious if there are any plans for extending ReadOptions to include a flag of some sort, which, when when set, would result in Get(), Seek() etc to return some special value that indicates that the data is not available in any cache(KVs, blocks) and RocksDB would need to perform disk I/O to satisfy the request, analogous to EWOULDBLOCK/EAGAIN for non-blocking disk and network I/O. That way, a read that could not be immediately processed without disk I/O would, for example, result in suspending the current thread, so that a thread in a thread pool could execute the request and when the results are available, the suspended thread would be provided the result in order to resume execution, again, like one would deal with blocking disk I/O where blocking IOps would be deferred to some threads pool.