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.

mini-lsm-book/src/week1-04-sst.md

@@ -11,4 +11,7 @@ In this chapter, you will:
 
 ## Task 2: SST Iterator
 
+## Task 3: Block Cache
+
 {{#include copyright.md}}
+``

mini-lsm-book/src/week1-05-read-path.md

@@ -10,8 +10,8 @@ In this chapter, you will:
 
 ## Task 1: Two Merge Iterator
 
-## Task 3: Read Path - Get
+## Task 2: Read Path - Get
 
-## Task 4: Read Path - Scan
+## Task 3: Read Path - Scan
 
 {{#include copyright.md}}