[Feature Request] Support non-seekable file descriptors (e.g. FIFOs) for snapshot memory output

Motivation

It would be useful to point mem_file_path at a FIFO (named pipe) so snapshot memory can be streamed to another process (e.g. compression, encryption, or upload) without first landing on local disk.

Currently this doesn't work because dump()/dump_dirty() in src/vmm/src/vstate/memory.rs require the writer to implement Seek, and snapshot_memory_to_file in src/vmm/src/vstate/vm.rs calls file.set_len() before writing. Both operations fail on non-seekable file descriptors (ESPIPE).

Worse, the failure is silent — when mem_file_path is a FIFO, the CreateSnapshot API hangs indefinitely instead of returning an error. The .unwrap() on the seek call causes a panic or unrecoverable internal state:

  fn dump<T: WriteVolatile + std::io::Seek>(&self, writer: &mut T) -> Result<(), MemoryError> {
      self.iter()
          .flat_map(|region| region.slots())
          .try_for_each(|(mem_slot, plugged)| {
              if !plugged {
                  let ilen = i64::try_from(mem_slot.slice.len()).unwrap();
                  writer.seek(SeekFrom::Current(ilen)).unwrap();  // panics on FIFO
              } else {
                  writer.write_all_volatile(&mem_slot.slice)?;
              }
              Ok(())
          })
          .map_err(MemoryError::WriteMemory)
  }

Describe the desired solution

Two separable improvements:

1. Fail fast: If mem_file_path is not a regular file (or if set_len() / seek() fails), return a clear API error instead of hanging.

2. Support non-seekable fds: For unplugged memory slots, dump() uses seek(SeekFrom::Current(n)) to skip over them. On a non-seekable fd, this could be replaced with writing n zero bytes. The set_len() pre-allocation could be skipped when the target is not a regular file.

3. The diff-snapshot path (dump_dirty) has the same pattern — skip clean pages via seek, write dirty pages — and could be adapted similarly.

Checks

• Have you searched the Firecracker Issues database for similar requests?
• Have you read all the existing relevant Firecracker documentation?
• Have you read and understood Firecracker's core tenets?