Allow retrieving compressed chunks

VDDK always decompresses the chunks it retrieves. However, some
callers may be interested in the compressed chunks, which may
be forwarded to another service involved in the backup process.

We'll add a read flag (skip_decompression). If set, the read
operation will return a "ReadResult" container, containing
a list of fragments and their compressed / decompressed lengths.

If the returned buffer size matches the AIO buffer size (which
now becomes configurable), at most one fragment will be returned.

While at it, we're adding perf tests that check various AIO buffer
sizes, cross checking against VDDK.

docs/reverse_engineering_procedure.md

@@ -250,7 +250,9 @@ What that comparison showed:
 - Request size stays 44; data is extra after the payload.
 - VDDK sends **one** request even when `length > 65536`. The server
   replies with several type-7 messages that share `opId`, each with a
-  chunk length at payload offset 32 (max 65536).
+  chunk length at payload offset 32 (max = OPEN_SESSION bufSize;
+  default 65536). `vixDiskLib.nfcAio.Session.BufSizeIn64KB=32` makes
+  that 2 MiB (`docs/probing_samples/vddk_aio_bufsize_probe.py`).
 - Treating offset 36 as `NFC_DISK` (`2`) was a 1-sector coincidence;
   VDDK repeats the byte length there.
 - Zeros on the wire are real transferred zeros, not a sparse skip.