refactor(pool): replace futures-intrusive semaphore with asyncband

[tisonkun]

Summary

Replace the futures-intrusive semaphore in sqlx-core with asyncband 0.7.1 for smol, async-global-executor, and async-std when Tokio is disabled. Continue using Tokio's semaphore whenever Tokio is enabled, including mixed-runtime feature builds, preserving cooperative scheduling and tracing/tokio-console integration. Make asyncband optional so Tokio-only builds do not depend on it.

Preserve the pool's permit ownership, manual release, and close-event protocol. Add deterministic tests for FIFO acquisition after waiter cancellation, cancellation of a partially satisfied pool close, and returning child-pool permits to the parent.

Does your PR solve an issue?

Partially addresses #1668 by removing futures-intrusive from sqlx-core. sqlx-sqlite still uses its mutex, so this does not close that issue.

Is this a breaking change?

No change to the supported SQLx API or its FIFO pool-acquisition contract. Remove the doc-hidden, benchmarking-only PoolOptions::__fair method and the fair argument of sqlx-core::sync::AsyncSemaphore::new, since both semaphore backends are always fair. The sqlx-core API is explicitly SemVer-exempt.

Validation

• SQLite-backed any-pool tests on Tokio, smol, async-global-executor, async-std, and Tokio + smol: 6 passed and 1 existing ignored test per configuration.
• Existing sqlite integration tests on Tokio and smol, using clean database fixtures: 44 passed and 1 existing ignored test per runtime.
• cargo test -p sqlx-core --all-features: 7 unit tests and 30 doc tests passed; 31 doc tests ignored.
• cargo clippy -p sqlx-core --all-targets --all-features -- -D warnings
• cargo clippy -p sqlx-core --no-default-features --features _rt-smol -- -D warnings
• cargo check -p sqlx-core --no-default-features and cargo fmt --all -- --check
• Dependency-tree checks confirm Tokio-only sqlx-core builds do not include asyncband, while smol builds enable version 0.7.1.

AI assisted with the implementation, tests, and PR draft.

[tisonkun]

Background:

• https://github.com/apache/asyncband

This Semaphore is always fair and does not integrate with tokio-console's traces.

[abonander]

Replacing the Tokio implementation is a non-starter, but I'm willing to consider this as an alternative for futures-intrusive.

We want to use Tokio's primitives where applicable, mainly because they integrate with Tokio's cooperative task scheduling, which is important for mitigating against high tail latencies. The tracing and tokio-console integration is also potentially very useful for observability and debugging.

[tisonkun]

OK. Let me try to narrow the scope to futures-intrusive first.

[abonander]

Does asyncband using only the Apache-2.0 license potentially cause problems downstream? Apache-2.0 isn't compatible with GPLv2, so this would potentially be a breaking change in license compatibility. Most Rust crates are Apache-2.0 OR MIT for this reason.

I don't have license information for our full dependency tree easily at hand, but I'm not aware of any other dependency that isn't either dual-licensed or just MIT-licensed (like Tokio).