Fix BuilderStart race, parallelize container build tests. (#2002)

- Closes #2001.
- Handle "container exists" error gracefully instead
  of failing, when trying to start the buildkit container.
- Move build tests to parallel suites, while the builder
  lifecycle tests remain serial. Parallel builds don't
  use the fixture lock that deletes and restarts the
  builder and runs a build block in isolation.

Author: jglogan

Sources/ContainerCommands/Builder/BuilderStart.swift

@@ -292,11 +292,17 @@ extension Application {
                 .setDescription("Starting BuildKit container")
             ])
 
-            try await client.create(
-                configuration: config,
-                options: .default,
-                kernel: kernel
-            )
+            do {
+                try await client.create(
+                    configuration: config,
+                    options: .default,
+                    kernel: kernel
+                )
+            } catch let error as ContainerizationError where error.code == .exists {
+                // A concurrent `container build` invocation already created the builder
+                // while we were fetching the image/kernel above. `bootstrap` below is
+                // idempotent, so just proceed against the container the winner created.
+            }
 
             try await startBuildKit(client: client, id: Builder.builderContainerId, progressUpdate, taskManager)
             log.debug("starting BuildKit and BuildKit-shim")

Sources/ContainerTestSupport/BuildFixture.swift

@@ -94,42 +94,6 @@ extension ContainerFixture {
         }
         throw CommandError.executionFailed("timed out waiting for container-builder-shim on buildkit")
     }
-
-    /// Deletes any existing builder, starts a fresh one, runs `body`, then deletes the builder.
-    ///
-    /// Each build test gets an isolated builder to avoid inter-test contamination.
-    /// Acquires a process-wide lock so only one test holds the buildkit singleton at a time,
-    /// regardless of how many suites run concurrently in the global pass.
-    public func withBuilder(
-        cpus: Int64 = 2,
-        memoryInGBs: Int64 = 2,
-        _ body: @Sendable (ContainerFixture) async throws -> Void
-    ) async throws {
-        try await withoutActuallyEscaping(body) { escapingBody in
-            try await Self.builderLock.withLock { _ in
-                _ = try? self.run(["builder", "delete", "--force"])
-                try self.builderStart(cpus: cpus, memoryInGBs: memoryInGBs)
-                defer { _ = try? self.run(["builder", "delete", "--force"]) }
-                try await self.waitForBuilderRunning()
-                try await escapingBody(self)
-            }
-        }
-    }
-
-    /// Acquires the process-wide builder lock without starting a builder.
-    ///
-    /// Use this in tests that manually manage the builder lifecycle (e.g. lifecycle
-    /// tests that call ``builderStart()``/``builderStop()`` directly) so they
-    /// serialise correctly with tests that use ``withBuilder(_:)``.
-    public func withBuilderLock<T: Sendable>(_ body: @Sendable () async throws -> T) async throws -> T {
-        try await withoutActuallyEscaping(body) { escapingBody in
-            try await Self.builderLock.withLock { _ in
-                try await escapingBody()
-            }
-        }
-    }
-
-    private static let builderLock = AsyncLock()
 }
 
 // MARK: - Build context helpers

Sources/Services/ContainerAPIService/Client/ContainerClient.swift

@@ -71,6 +71,8 @@ public struct ContainerClient: Sendable {
             }
 
             try await xpcSend(message: request)
+        } catch let error as ContainerizationError {
+            throw error
         } catch {
             throw ContainerizationError(
                 .internalError,