update sst chapter outline

Signed-off-by: Alex Chi <iskyzh@gmail.com>

mini-lsm-book/src/week1-02-merge-iterator.md

@@ -25,6 +25,7 @@ error handling, order requirement
 * Why do we need a self-referential structure for memtable iterator?
 * If we want to get rid of self-referential structure and have a lifetime on the memtable iterator (i.e., `MemtableIterator<'a>`, where `'a` = memtable or `LsmStorageInner` lifetime), is it still possible to implement the `scan` functionality?
 * What happens if (1) we create an iterator on the skiplist memtable (2) someone inserts new keys into the memtable (3) will the iterator see the new key?
+* What happens if your key comparator cannot give the binary heap implementation a stable order?
 * Why do we need to ensure the merge iterator returns data in the iterator construction order?
 * Is it possible to implement a Rust-style iterator (i.e., `next(&self) -> (Key, Value)`) for LSM iterators? What are the pros/cons?
 * The scan interface is like `fn scan(&self, lower: Bound<&[u8]>, upper: Bound<&[u8]>)`. How to make this API compatible with Rust-style range (i.e., `key_a..key_b`)? If you implement this, try to pass a full range `..` to the interface and see what will happen.