add question on alternative snapshot implementation

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

mini-lsm-book/src/week3-01-ts-key-refactor.md

@@ -105,3 +105,6 @@ Now that we have a timestamp in the key, and when creating the iterators, we wil
 When you check if a user key is in a table, you can simply compare the user key without comparing the timestamp.
 
 At this point, you should build your implementation and pass all week 1 test cases. We will make the engine fully multi-version and pass all test cases in the next two chapters.
+
+
+{{#include copyright.md}}

mini-lsm-book/src/week3-02-snapshot-read-part-1.md

@@ -24,3 +24,8 @@ pass all tests except week 2 day 6
 
 * What is the difference of `get` in the MVCC engine and the engine you built in week 2?
 * In week 2, you stop at the first memtable/level where a key is found when `get`. Can you do the same in the MVCC version?
+
+We do not provide reference answers to the questions, and feel free to discuss about them in the Discord community.
+
+
+{{#include copyright.md}}

mini-lsm-book/src/week3-03-snapshot-read-part-2.md

@@ -17,3 +17,9 @@ do not implement put and delete
 ## Test Your Understanding
 
 * So far, we have assumed that our SST files use a monotonically increasing id as the file name. Is it okay to use `<level>_<begin_key>_<end_key>_<max_ts>.sst` as the SST file name? What might be the potential problems with that?
+* Consider an alternative implementation of transaction/snapshot. In our implementation, we have `read_ts` in our iterators and transaction context, so that the user can always access a consistent view of one version of the database based on the timestamp. Is it viable to store the current LSM state directly in the transaction context in order to gain a consistent snapshot? (i.e., all SST ids, their level information, and all memtables + ts) What are the pros/cons with that? What if the engine does not have memtables? What if the engine is running on a distributed storage system like S3 object store?
+
+We do not provide reference answers to the questions, and feel free to discuss about them in the Discord community.
+
+
+{{#include copyright.md}}

mini-lsm-book/src/week3-04-watermark.md

@@ -3,3 +3,6 @@
 ## Task 1: Implement Watermark
 
 ## Task 2: Garbage Collection in Compaction
+
+
+{{#include copyright.md}}

mini-lsm-book/src/week3-05-txn-occ.md

@@ -5,3 +5,6 @@
 ## Task 2: Get and Scan
 
 ## Task 3: Commit
+
+
+{{#include copyright.md}}

mini-lsm-book/src/week3-06-serializable.md

@@ -9,3 +9,7 @@
 ## Test Your Understanding
 
 * If you have some experience with building a relational database, you may think about the following question: assume that we build a database based on Mini-LSM where we store each row in the relation table as a key-value pair and enable serializable verification, does the database system directly get ANSI serializable isolation level capability? Why or why not?
+
+We do not provide reference answers to the questions, and feel free to discuss about them in the Discord community.
+
+{{#include copyright.md}}

mini-lsm-book/src/week3-07-compaction-filter.md

@@ -1 +1,4 @@
 # Snack Time: Compaction Filter
+
+
+{{#include copyright.md}}