Adopt swift-subprocess when running unit tests

[owenv]

Alternative to #9191

Begin adopting swift-subprocess, beginning with test execution, in an effort to standardize on one implementation for process output streaming across platforms.

This required a bit of additional refactoring of the parallel test runner to make it async

Depends on swiftlang/swift#84947

[jakepetroules]

Can we introduce a convenience extension on Subprocess.Configuration that takes an array as an input? This pattern seems likely to appear elsewhere.

extension Subprocess.Configuration {
    init(commandLine: [String], environment: Environment) throws {
        guard let arg0 = commandLine.first else {
            throw ItsEmpty()
        }
        self.init(.path(arg0), .init(Array(commandLine.dropFirst())), environment: environment)
    }
}

[jakepetroules]

I think this is unsafe. Because deregister is synchronous, it may return before the cancellation block has finished executing, meaning teardown could be called when the process is already dead. It is NOT safe to use execution once the body block has returned, as the pid may have already been recycled or the pidfd may have become invalid. This is one reason why Execution would probably ideally be ~Escapable...

Subprocess.run already response to Swift Concurrency task cancellation, so you'd want something like this:

extension Cancellator {
    func run<T: Sendable>(_ block: @escaping @Sendable () async throws -> T) async throws -> T {
        let task = Task { try await block() }
        let token = register(name: "Test Execution", handler: { _ in task.cancel() })
        defer {
            token.map { deregister($0) }
        }
        return try await task.value
    }
}

try await cancellator.run {
    try await Subprocess.run(...)
}

That said, do you even need the cancellator, or is cooperative cancellation on its own, enough?

[jakepetroules]

remove debugging code

[jakepetroules]

nit but also kinda seriously: I'd either use an AsyncStream or at least use a LockedValue or similar abstraction.

[bkhouri]

Can we refactor the SwiftTestCommand so we can write 'small' or 'medium' tests, that is, we test the modified functions/code in isolation, as opposed to relying on 'large' (ie: end-to-end tests)?

[bkhouri]

Meant to mark this as required changed instead of approve