In coroutines, Redis connections are released immediately after all commands except multi-exec commands like pipeline(). This causes rapid Redis connection pool exhaustion when using pipeline() in long-running coroutines (see: #7351).

I don't think there's any reason to hold the connection after a multi-exec callback has finished executing. This PR releases Redis connections immediately after exec() is called in pipeline/transaction operations that use callbacks (rather than deferring the release until the coroutine completes).

Note: This improvement only applies to callback-based usage:

$redis->pipeline(function($pipe) { ... }); // ✓ Immediate release after callback completes

Manual usage continues to use the existing deferred cleanup:

$pipe = $redis->pipeline(); // $callback is null, still released at coroutine end
$pipe->set('key', 'value');
$pipe->exec();

Changes:

• Modified MultiExec trait to explicitly release connections in finally blocks after pipeline/transaction callback execution
• Added contextKey tracking to RedisConnection to properly manage connection context
• Updated defer logic in Redis::__call() to prevent double-releasing connections

Real-world Impact:

With this change, I successfully ran 100+ concurrent long-running coroutines using Redis pipeline() callbacks, with the Redis pool max_connections set to just 10, and experienced no connection pool exhaustion. Previously, the same code would exhaust the connection pool after only 10 coroutines, creating a scaling problem under high load. This is a significant improvement in connection efficiency.

Benefits:

• Prevents connection pool exhaustion in long-running coroutines when using multi-exec commands with callbacks
• Maintains full backwards compatibility for existing code
• No breaking changes - connections are still properly managed for all use cases