Named DB listeners: support DB::startListen($key, $callback) and DB::stopListen($key)

[JavierDavalos1988]

Feature Request: Named DB listeners

Problem

Laravel currently allows registering database query listeners via DB::listen($callback). However, it does not offer a way to remove listeners after they've been added, nor does it support scoping them to specific contexts such as jobs, tests, or timed segments.

This makes it hard to build metrics systems, profilers, or conditional logging tools that need to attach/detach listeners dynamically.

---

Proposed Solution

Introduce the ability to add named query listeners, and later remove them by name:

DB::startListen('metrics', function ($query) {
    // Store to Redis or log for metrics
});

DB::stopListen('metrics');
This would allow developers to scope listeners to specific operations, such as:

Monitoring queries per queued job

Temporarily enabling query tracking in performance analysis

Cleaning up listeners at the end of a request or test

Current Workarounds
Overriding the database manager with custom logic

Using static state to ignore callbacks after a certain point

Calling DB::clearResolvedInstances() or DB::purge() (aggressive and risky)

Why This Belongs in Laravel Core
The feature is generic and fits into Laravel's expressive, developer-friendly style.

Encourages better diagnostics and metrics in apps and packages.

Avoids leaks and improves safety in long-lived processes or multi-queue workers.

Keeps developer code clean without forcing manual workarounds.

Backward Compatibility
This would not break existing behavior — DB::listen() continues working the same way. Named listeners would be an optional enhancement.

Possible Implementation Sketch
Internally, the DatabaseManager could maintain an associative array:

protected array $namedListeners = [];

public function startListen(string $key, Closure $callback)
{
    $this->namedListeners[$key] = $callback;
    $this->listen($callback);
}

public function stopListen(string $key)
{
    unset($this->namedListeners[$key]);
    // Not currently supported: would require access to listener stack
}
To fully implement stopListen(), a low-level way to unregister a listener would need to be added (or at least ignore callbacks internally).

Thanks for considering this! Happy to provide a working PR if the idea is accepted.