#200: fix double-release and use-after-free of pooled PDO connections

[EdmondDantes]

Fixes true-async/php-async#200.

The bug

async_scheduler_launch() promotes the already-running main flow into the main coroutine on the fly, the first time something needs the scheduler (in the report: file_put_contents). The PDO pool keys its per-context binding by coroutine identity, so ZEND_ASYNC_CURRENT_COROUTINE going NULL -> main mid-execution changed the key underneath a live connection.

Traced with an instrumented build:

acquire coro=(nil) key=0            <- exec()/prepare(), before the launch
peek    coro=0x...2f00 key=3        <- statement destructor, after it
        binding=(nil)               <- lookup misses
free_conn conn=0x...3400 methods=0x562dc21eed60
free_conn conn=0x...3400 methods=0x71bdd1ca3600   <- same conn, freed twice

The statement destructor missed the binding, took the "orphaned connection" branch and returned the conn to the pool; the binding still owned it and returned it again at pool destroy. The idle list then held it twice and the pool destructor freed it twice — the conn->methods guard in pdo_pool_free_conn passed because the memory was non-NULL, not because it was valid.

The fix

Key stability. The main flow maps to binding key 0 whether or not the scheduler has launched, so one execution context keeps one binding across the promotion. Object handle 0 is reserved by the objects store, so no coroutine collides with it.

Ownership. A pooled slot carries an owner_binding back-pointer. Every release path detaches the owner first, so a double release is impossible even when the key legitimately drifts — a statement destroyed in a different coroutine, or a binding freed at coroutine finalize while statements still borrow the connection.

Destruction order. A statement no longer dereferences stmt->dbh on the release path at all. The slot holds its own reference on the pool event and is released through conn->pool, so it works in any order, including GC freeing the PDO before the statement. pdo_mysql_stmt_dtor had the same stale-dbh read (pefree(..., stmt->dbh->is_persistent)) and is now guarded exactly like the stmt-cache code eight lines below it.

PDO_DRIVER_API is bumped for the new pdo_dbh_t field.

Tests

Seven new tests, all sqlite-based except one so they need no server:

test	covers
pool_006	the reported scenario: statement outlives the PDO after a lazy scheduler launch
pool_007	statement outlives the coroutine that acquired its connection
pool_008	open transaction on an orphaned connection is rolled back
pool_009	GC frees the PDO before its statement
pool_010	transaction opened before the scheduler launch survives it
pool_011	pre-launch binding still releases at main-coroutine end
pdo_pool_021	a failed query() does not burn a pool slot

Each was verified to fail with its corresponding change reverted, not merely to pass — pool_010 and pool_011 in particular, because the ownership layer masks the key-stability fix: without them, reverting the core change of this PR passed all 22 existing tests silently while losing a committed transaction and deadlocking a coroutine.

The pool tests in ext/pdo/tests also resolve their helper through REDIR_TEST_DIR instead of __DIR__. Under --REDIRECTTEST-- run-tests materialises the skip file in the driver's directory, so __DIR__ pointed at ext/pdo_sqlite/tests/ and 11 tests borked out without running at all. BORKED went 22 -> 0.

Verification

ext/pdo_sqlite + ext/pdo_mysql + ext/pdo	706 tests, 0 failed, 0 borked
full async suite	1124 passed, 0 failed
pool tests	sqlite 11/11, mysql 13/13
valgrind on all four reproducers	0 errors, no definite leaks

Reproducers checked under USE_ZEND_ALLOC=0 valgrind: the original report, statement-outlives-coroutine, the GC-ordering case, and the failed-query() slot accounting. The GC case is worth calling out — it printed Done and exited 0 while writing into freed memory, so it was only visible under valgrind.

Not in this PR

Found while auditing this code path, filed separately: true-async/php-async#201, php#202, php#203. php#202 in particular is now precisely located (pdo_pool.c coroutine-finalize callback dereferences binding->dbh after a release that suspended) but its fix belongs after this lands, since it touches the same paths.