Use correct containerd error detection.

[xenoscopic]

@thaJeztah suggested a more idiomatic approach to error detection. Also we can use the container name rather than ID for inspection, so we don't even need to capture it from the error message.

[thaJeztah]

I just had a thought; given that the "start" endpoint is effectively idempotent for containers that are already started, we could take advantage of that, and after we verified we either created the container, or got a "conflict" (already exists), we can probably just use container start with a retry;

https://github.com/moby/moby/blob/5318877858c9fc94b5cccc3cf1a75d4ec46951b8/daemon/start.go#L76-L93

func (daemon *Daemon) containerStart(ctx context.Context, daemonCfg *configStore, container *container.Container, checkpoint string, checkpointDir string, resetRestartManager bool) (retErr error) {
	ctx, span := otel.Tracer("").Start(ctx, "daemon.containerStart", trace.WithAttributes(append(
		labelsAsOTelAttributes(container.Config.Labels),
		attribute.String("container.ID", container.ID),
		attribute.String("container.Name", container.Name),
	)...))
	defer func() {
		otelutil.RecordStatus(span, retErr)
		span.End()
	}()

	start := time.Now()
	container.Lock()
	defer container.Unlock()

	if resetRestartManager && container.Running { // skip this check if already in restarting step and resetRestartManager==false
		return nil
	}

I haven't verified the approach, but let me write up a quick patch with that idea

[thaJeztah]

@xenoscopic OK; I pushed a PR that's opened against this branch (but feel free to squash it)

⚠️ I have NOT tested it, so probably good if you could give it a spin; let me know what you think!

• simplify container start logic, taking advantage of idempotency #99