Retry when a reported readiness turns out to be stale

[colemancda]

Follow-up to #24 and #26, from the same investigation. An I/O operation could fail with EWOULDBLOCK — surfaced to the caller as "Resource temporarily unavailable" — even though nothing was wrong with the socket.

The problem

pendingEvents records that a socket was reported ready by the poller, and it is only cleared by a successful transfer (didRead / didWrite). wait(for:fileDescriptor:) short-circuits when the flag is already set:

guard await socket.pendingEvents.contains(events) == false else {
    return socket // execute immediately
}

So the flag is a claim about the past — "this was ready at some point" — used as if it were a claim about the present. Two operations on the same socket can both observe it set and both skip waiting; whichever runs second finds the socket no longer ready and fails. The same happens whenever readiness is consumed between the poll and the call.

The failure is reported to the caller as an error, so a perfectly healthy socket surfaces a spurious failure under load. It showed up as roughly 1 CI job in 16 in the pure-Swift D-Bus suite, on the more contended runners.

The fix

EWOULDBLOCK from a non-blocking socket does not mean "this failed", it means "not ready after all". A new perform(_:for:_:) helper waits for readiness, runs the operation, and on EWOULDBLOCK / EAGAIN clears the stale readiness and waits for a genuine one before retrying:

while true {
    let socket = try await wait(for: events, fileDescriptor: fileDescriptor)
    do { return try await body(socket) }
    catch let error as Errno where error == .wouldBlock || error == .resourceTemporarilyUnavailable {
        await socket.clearPending(events)
    }
}

Clearing the flag is what makes the retry correct rather than a spin: the next wait no longer short-circuits, so it registers interest and suspends until the poller reports readiness again.

Every read, write, message and accept path now goes through it, so the behavior is uniform rather than per-call-site.

Verification

Three consecutive full runs of the pure-Swift D-Bus suite (205 tests) pass, and the Socket ancillary tests pass. The failure this fixes is load-dependent and was observed in CI rather than locally, so the direct evidence is the CI matrix rather than a local reproduction.

The pre-existing failures on this repo — the force unwrap at NetworkInterface.swift:58, and the fixed-port and fixed-path tests colliding with leftovers from earlier runs — are untouched here and fail the same way on main.