[DependencyInjection][EventDispatcher] Order tagged services and listeners with before/after constraints - #66012

Priorities cannot express "run between these two" when the two services share a priority and are declared by bundles you do not control. That is the case @aboks opened #64580 with, and inventing a number does not solve it.

This adds before and after constraints, resolved at compile time:

#[AsTaggedItem(after: BundleB\Handler::class, before: BundleC\Handler::class)]
class MyHandler
{
}

services:
    App\Handler\TsvHandler:
        tags:
            - name: app.handler
              before: App\Handler\CsvHandler

Event listeners are covered too, which is where the pain is most common:

#[AsEventListener(event: 'kernel.request', before: ProfilerListener::class)]
class MyListener
{
}

How it orders

Constraints are applied on top of the existing order rather than replacing it. The priority sort seeds the result, then items move only as far as the constraints require, depth-first in seed order. A before B and B after A describe the same edge and give the same result.

A target is matched by service id first, then by class, so SomeClass::class works for autoconfigured services without introducing a second referent.

A target that is not in the collection is ignored, so a constraint pointing at an optional bundle does not become fatal when that bundle is absent. A cycle throws at compile time, naming the services it runs through.

Event listeners

The runtime order for one event is (priority DESC, insertion ASC), so RegisterListenersPass reorders the addListener() calls and raises a priority only when a constraint puts a listener ahead of a higher-priority one. The listener that declared the constraint moves; the one it points at keeps its priority.

Two consequences worth knowing:

• a raised listener also moves ahead of listeners added at runtime between the two priorities;
• subscribers can be targeted but cannot declare constraints, since getSubscribedEvents() has no slot for them.

A collection with no constraints produces byte-identical addListener() calls, which I checked against 8.2 on a container mixing priorities, two dispatchers, multi-tag listeners and a subscriber registering twice on one event.

Targeting a single listener

Naming a service targets every registration it has on that event, which is too coarse when a service listens twice. LocaleListener subscribes to kernel.request with setDefaultLocale at 100 and onKernelRequest at 16, so a constraint has to be able to name one of them:

#[AsEventListener(event: 'kernel.request', before: LocaleListener::class.'::onKernelRequest')]

Both halves accept a service id or a class, so 'locale::onKernelRequest' works too. If the service part is present on that event but the method is not one of its listeners, it throws, since the constraint would otherwise silently do nothing:

Invalid "before" constraint on listener "a": "sub" does not listen to event "event" with method "onLat".

A target whose service part is absent stays ignored, so an uninstalled bundle is still not fatal. This is listener-only; tagged services have no method dimension.

On the algorithm

#64580 floated C3 linearization. It does not fit: C3 preserves the relative order of every pair inside each input list, so feeding it the priority order as the tie-break turns every incidental adjacency into a hard constraint, and c3merge([C, A], [A, B, C]) then fails on the simplest possible input. Its distinguishing property over a topological sort is monotonicity across an inheritance hierarchy, and a tag produces exactly one linearization, so there is nothing to be monotonic with respect to.

A depth-first topological sort in seed order is used instead. Compared with Kahn's algorithm seeded the same way, both are valid topological sorts with the same displacement, but Kahn moves the wrong element: for J before B over A..J it demotes B to last, where the depth-first order promotes J. Demoting a third-party listener nobody constrained is not something a metric catches.