Reuse canine backend (docker transient) across different proceesses

[getzlab]

Reuse canine backend (docker transient) across different proceesses

[agraubert]

I think this is definitely doable. I don't think that sharing instances directly between processes is safe, but I think there's a very simple solution.

Only one backend is created, using the user's configuration. This backend should be in the "main" process and persist though the lifetime of the program. When workflow instances are started, they each start their own backend from one of the two base classes. That way, they can connect to a functional slurm cluster without dealing with setup, cleanup, or state.

For example:

If the user wants to create a cluster using the TransientImage backend, one master instance is created, which spins up the cluster. Afterwards, new workflows in other processes can simply use the Local backend to connect to the existing cluster.

This would require adding a method to each backend that generates valid backend instances to connect to their own cluster.

---

LocalSlurmBackend -> LocalSlurmBackend
RemoteSlurmBackend -> RemoteSlurmBackend
TransientGCPSlurmBackend -> RemoteSlurmBackend (connect's to master node's hostname)
TransientImageSlurmBackend -> LocalSlurmBackend
DockerTransientImageSlurmBackend -> ?
DummySlurmBackend -> ?

The two docker-based backends would need a new barebones docker backend which simply invoke()s commands through the slurm controller container

[julianhess]

The Docker backend does not store any state in the Python class, so it is already safe to spin up multiple Docker backends. 4aa362b allows the backend's __enter__ method to detect a valid running Slurm controller container and simply use that if it exists. The __exit__ method will not shut down the container if it was already running.

TODO: the __exit__ method should not shut down the NFS if the container was already running. However, this won't be fixed here, since I'm planning on deprecating the separate NFS server, and just running it from the controller machine.

I think we should have a separate wolF server process that spins up the controller container and Prefect server, but that's for another PR.