[FEATURE] Split soci snapshotter into fuse and snapshotter processes

[Kern--]

Description

Today, the SOCI snapshotter process itself acts as both the snapshotter and the host process for the FUSE mountpoints used by each image layer. The major drawback of this approach is that if the snapshotter dies for any reason, then all running containers also die. A secondary drawback is that all containers are pulled in the network namespace that the snapshotter was launched in. With non-remote snapshotters, the pulling process can be launched in any network namespace which gives more control over what network resources any particular puller can access.

Describe the solution you'd like

It's worth investigating splitting the snapshotter into multiple processes:

1. The snapshotter that interfaces with containerd
2. A FUSE host either per-layer or per-container that hosts the FUSE processes used to lazy load layers.

There are several open questions that I can think of (and probably many more that would come up if we started looking). For, example:

1. Should the FUSE host be per-layer or per-container?
2. Should namespace awareness be a property of this system?
3. Does there need to be a 3rd process that does the initial SOCI index pull in the right network namespace?

Describe any alternative solutions/features you've considered

It's possible this is additional architectural complexity that isn't actually needed. It would be worth trying to gather community feedback on whether this is a real problem for people.

Any additional context or information about the feature request

The stargz community has been trying to implement a similar change for quite a while containerd/stargz-snapshotter#324