Handle vsock connection resets and network IP/TAP-name conflicts when snapshotting and restoring/cloning Firecracker microVMs

Documented steps

1. Expect packet loss and lost connection state for both network and vsock whenever a guest resumes from a snapshot in a different Firecracker process — design for reconnection.
2. Vsock: at snapshot creation, Firecracker sends VIRTIO_VSOCK_EVENT_TRANSPORT_RESET to the guest driver; on resume the driver closes all connections that were open at snapshot time, but existing listen sockets stay active (CID updated to the current guest_cid) and accept new connections.
3. Before PUT /snapshot/load, recreate the vsock backing unix socket (like disks and TAPs) at the same relative path the original microVM used.
4. Network clones: Firecracker restores network devices by original TAP name and every clone resumes with the same guest IP — start each clone in its own network namespace: `sudo ip netns add fc0` then `sudo ip netns exec fc0 ip tuntap add name vmtap0 mode tap` (bind the process to the namespace with the jailer's --netns parameter).
5. Give each clone host connectivity via a veth pair into its namespace plus iptables MASQUERADE/DNAT rules, so clones sharing an internal IP remain reachable — per the example commands in network-for-clones.md.
6. If the TAP name at restore differs from snapshot time (TAP pools), remap via network_overrides on PUT /snapshot/load: {"snapshot_path": "./snapshot_file", "mem_backend": {"backend_path": "./mem_file", "backend_type": "File"}, "network_overrides": [{"iface_id": "eth0", "host_dev_name": "vmtap01"}]}, then fix guest IP/routes/ARP as needed.
7. Official docs: https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md and https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/network-for-clones.md