fix(doc): Improve accurancy of snapshot documentation

Fix various minor errors:
- Drop some specifics on the cgroups v1 disclaimer, because all
  supported host kernel versions are "5.4+"
- Do not claim that creating a snapshot has no effect on the running
  VM, because that's not true.
- Cut down on some repeated and confusing information / examples near
  the end.

Signed-off-by: Patrick Roy <roypat@amazon.co.uk>

Author: roypat

docs/snapshotting/snapshot-support.md

@@ -122,7 +122,7 @@ the feature can be combined with guest_memfd support in Firecracker.
 
 ### Limitations
 
-- High snapshot latency on 5.4+ host kernels due to cgroups V1. We strongly
+- High snapshot restoration latency when cgroups V1 are in use. We strongly
   recommend to deploy snapshots on cgroups V2 enabled hosts for the implied
   kernel versions -
   [related issue](https://github.com/firecracker-microvm/firecracker/issues/2129).
@@ -145,10 +145,10 @@ the feature can be combined with guest_memfd support in Firecracker.
   resumed from snapshot load memory on-demand from the snapshot and
   copy-on-write to anonymous memory.
 - Resuming from a snapshot is optimized for speed, while taking a snapshot
-  involves some extra CPU cycles for synchronously writing dirty memory pages to
-  the memory snapshot file. Taking a snapshot of a fresh microVM, on which dirty
-  pages tracking is not enabled, results in the full contents of guest memory
-  being written to the snapshot.
+  involves some extra CPU cycles for synchronously writing memory pages to the
+  memory snapshot file. Taking a full snapshot of a microVM results in the full
+  contents of guest memory being written to the snapshot, and particularly, in
+  all guest memory being faulted in.
 - The _memory file_ and _microVM state file_ are generated by Firecracker on
   snapshot creation. The disk contents are _not_ explicitly flushed to their
   backing files.
@@ -353,10 +353,12 @@ Enabling this support enables KVM dirty page tracking, so it comes at a cost
 (which consists of CPU cycles spent by KVM accounting for dirtied pages); it
 should only be used when needed.
 
-Creating a snapshot will **not** influence state, will **not** stop or end the
-microVM, it can be used as before, so the microVM can be resumed if you still
-want to use it. At this point, in case you plan to continue using the current
-microVM, you should make sure to also copy the disk backing files.
+Creating a snapshot has some minor effects on the currently running microVM:
+
+- The vsock device is [reset](#vsock-device-reset), causing the driver to
+  terminate connection on resumption.
+- On x86_64, a notification for KVM-clock is injected to notify the guest about
+  being paused.
 
 ### Resuming the microVM
 
@@ -381,8 +383,8 @@ ignored (microVM remains in the running state). **Effects**:
 ### Loading snapshots
 
 If you want to load a snapshot, you can do that only **before** the microVM is
-configured (the only resources that can be configured prior are the Logger and
-the Metrics systems) by sending the following API command:
+configured (the only resources that can be configured prior are the logger and
+the metrics systems) by sending the following API command:
 
 ```bash
 curl --unix-socket /tmp/firecracker.socket -i \
@@ -469,28 +471,10 @@ to the new Firecracker process as they were to the original one.
 - _on failure_: A specific error is reported and then the current Firecracker
   process is ended (as it might be in an invalid state).
 
-*Notes*: Please, keep in mind that only by setting to true
-`enable_diff_snapshots`, when loading a snapshot, or `track_dirty_pages`, when
-configuring the machine on a fresh microVM, you can then create a `diff`
-snapshot. Also, `track_dirty_pages` is not saved when creating a snapshot, so
-you need to explicitly set `enable_diff_snapshots` when sending
-`LoadSnapshot`command if you want to be able to do diff snapshots from a loaded
-microVM. Another thing that you should be aware of is the following: if a fresh
-microVM can create diff snapshots, then if you create a **full** snapshot, the
-memory file contains the whole guest memory, while if you create a **diff** one,
-that file is sparse and only contains the guest dirtied pages. With these in
-mind, some possible snapshotting scenarios are the following:
-
-- `Boot from a fresh microVM` -> `Pause` -> `Create snapshot` -> `Resume` ->
-  `Pause` -> `Create snapshot` -> ... ;
-- `Boot from a fresh microVM` -> `Pause` -> `Create snapshot` -> `Resume` ->
-  `Pause` -> `Resume` -> ... -> `Pause` -> `Create snapshot` -> ... ;
-- `Load snapshot` -> `Resume` -> `Pause` -> `Create snapshot` -> `Resume` ->
-  `Pause` -> `Create snapshot` -> ... ;
-- `Load snapshot` -> `Resume` -> `Pause` -> `Create snapshot` -> `Resume` ->
-  `Pause` -> `Resume` -> ... -> `Pause` -> `Create snapshot` -> ... ; where
-  `Create snapshot` can refer to either a full or a diff snapshot for all the
-  aforementioned flows.
+*Notes*: The `track_dirty_pages` configuration is not saved when creating a
+snapshot, so you need to explicitly set `track_dirty_pages` again when sending
+the `LoadSnapshot` command if you want to be able to do dirty page tracking
+based diff snapshots from a loaded microVM.
 
 It is also worth knowing, a microVM that is restored from snapshot will be
 resumed with the guest OS wall-clock continuing from the moment of the snapshot