Clarification on OverlayFS Configuration for Firecracker VMs via Flintlock gRPC API

**Describe the solution you'd like:**
We are working on integrating Flintlock (via its gRPC API) to manage Firecracker microVMs. Our goal is to optimize VM startup times and resource usage by employing an OverlayFS setup where:
1. The base root filesystem is a read-only SquashFS image (e.g., base.squashfs).
2. The writable upper layer for session-specific changes is backed by tmpfs on the host.

We've reviewed the documentation and I'm not sure if Flintlock supports OverlayFS. Also, we need to clarify the exact mechanism for instructing Flintlock to use this specific layered approach when creating a new Firecracker microVM through its gRPC interface

**Why do you want this feature:**

Specifically, our question is:
When configuring a Firecracker microVM to use a SquashFS base image as a lower directory and a tmpfs-backed upper directory for OverlayFS:

A) Does Flintlock itself handle the mount -t overlay ... operation?

If so, how do we specify the paths to the read-only SquashFS file (lowerdir), the pre-created tmpfs path for the upperdir on the host, and the workdir path on the host via the Flintlock gRPC API? Are there specific fields in the MicroVMSpec (or elsewhere) for these distinct OverlayFS directories?

B) Or, does Flintlock expect the host system to have already mounted the OverlayFS?

If this is the case, would we then provide Flintlock with a single path to this pre-existing OverlayFS mount point as the VM's root_fs?

Could you please point us to the relevant API fields, configuration examples, or documentation that details how to correctly pass these parameters to Flintlock to achieve this SquashFS + tmpfs OverlayFS setup? Any insights into best practices for managing the host-side tmpfs directories (upperdir, workdir) in conjunction with Flintlock would also be highly appreciated.

Thanks for your help!

Start by inspecting Flintlock's gRPC API and MicroVMSpec definitions, then review existing documentation for root_fs and host-side filesystem handling. Determine whether OverlayFS is supported and where the lowerdir, upperdir, and workdir would be configured. Done means documenting the supported mechanism, relevant fields, and a configuration example.

Written by the indexing model from the issue text.