DB metadata mode causes slow restarts due to unnecessary remote footer/TOC reads

[wswsmao]

Problem

When running stargz-snapshotter with the DB-backed metadata store, restarting the snapshotter can be slow because it still performs remote reads against the registry to fetch the layer footer/TOC during initialization, even though the metadata is already stored on disk. This adds unnecessary network latency to the restart path.

test case

nerdctl pull --snapshotter stargz ghcr.io/stargz-containers/ubuntu:24.04-zstdchunked
nerdctl pull --snapshotter stargz ghcr.io/stargz-containers/python:3.13-zstdchunked

ls /var/lib/containerd-stargz-grpc/snapshotter/snapshots/
1  2  3  4  5  6  7  8  9

time systemctl restart stargz-snapshotter.service
real    0m14.576s
user    0m0.014s
sys     0m0.004s

Observed: restart takes ~14s with 9 layers.

Solution

Make the DB metadata store restart-friendly by:

• Keying persisted metadata by layer digest and adding a fast-path: if the DB already contains a complete metadata entry for that digest, open it directly and skip remote footer/TOC reads.
• Moving metadata cleanup from per-mount Close() to a prune step triggered when snapshots/layers are actually removed, so the DB does not grow unbounded while still allowing cross-restart reuse.