Potential optimization for incremental snapshotting

[superobertking]

• Keep the mapping after the orbit call (is the current implementation)
• Iterate through the page table entries, if it is still CoW, we can just keep it there, otherwise recreate the mapping
  • For orbit with two or more calls in the queue, we can either 1) keep the current implementation of using an intermediate snapshotting data structure for all PTEs, or 2) (an optimization for scenario that prohibits orbit to modify the pool) compare the diffs with the previous snapshots in the queue.
• If overhead of iterating through the pool is still very large, we can apply optimization that: in the page fault handler, update a flag to indicate whether a page fault has happened in a larger region (e.g. a PMD) since the last orbit call. Then in the next snapshot, we can skip those large regions.
• Add API option in orbit call, whether we want to tear down the mapping or not after/before the orbit call.