[BUG] Sometimes we attempt to control containers that don't exist

[BenElgar]

I believe the issue is a mismatch between what we refer to in exo as a container and what docker refers to as a container. Docker treats containers as disposable single use objects, to be lazily garbage collected at some undefined point in the future whilst, in exo, a container is really more akin to a docker-compose service. This causes problems when a docker container has been garbage collected by the docker daemon and we're still trying to interact with it:

e.g.

14:33:17    server 2021/12/07 14:33:17 container to be removed not found: "5df3bf4437c4acc2ec02ed219bf8734a7ca87057dc07980f534104181aeb55df"

More importantly this sometimes breaks the start mechanism, since the docker container may not exist when exo tries to start the container.

func (c *Container) Start(ctx context.Context, input *core.StartInput) (*core.StartOutput, error) {
	//c.Initialize(ctx, &core.InitializeInput{Spec: })
	if err := c.start(ctx); err != nil {
		return nil, fmt.Errorf("starting process container: %w", err)
	}
	return &core.StartOutput{}, nil
}

func (c *Container) start(ctx context.Context) error {
	err := c.Docker.ContainerStart(ctx, c.State.ContainerID, types.ContainerStartOptions{})
	if err != nil {
		c.State.Running = true
		return fmt.Errorf("starting container: %w", err)
	}
	return nil
}

[brandonbloom]

I think we can fix this as part of the other work I have planned to separate components from resources. Essentially, the component roughly correspond to the compose-style service with longer lifetime than the underlying container resource, which may be created/destroyed more freely.