[NFR]: Framework-neutral integration seam: boot and response injection without Mvc\Application #14

Summary

The debug bar can only be booted and injected against a Phalcon\Mvc\Application. This blocks non-MVC applications, notably ADR (Phalcon\ADR). #39 and #40 add the neutral core. This issue adds the ADR integration, so that an ADR app can boot the bar and inject it into an HTML response.

Why ADR does not work today

• The ADR container is Phalcon\Container\Container. It is not a Phalcon\Di\DiInterface.
• ADR never fires application:beforeSendResponse. The response is available at application:afterHandle (Phalcon\ADR\Application), and the ADR emitter writes it out after that.

Proposed direction

• Add an ADR service provider that implements Phalcon\Contracts\Container\Service\Provider. It:
  • reads the events manager and the request from the container
  • boots the neutral core
  • attaches the response step to application:afterHandle
• Use a service provider because AbstractHttpFront::boot() calls registerProviders() before run() calls getApplication(). The integration has the container at that point, but not the application.
• Register this provider last, after all other providers, and document this. The provider resolves the events manager and the request during registration. After that point, extend() on these services throws CannotExtendResolved, and set() has no effect.
• Update the requirements in docs/index.md:13 and the suggest entry in composer.json. ADR support needs Phalcon v5.18.0 or later, or Phalcon 6.
• Do not add an emitter hook. AbstractHttpFront::run() emits after handle() returns, and the existing listener already works on application:afterHandle.
• Keep ADR class references in the provider only, not in the core. Phalcon versions before v5.18.0 have no Phalcon\ADR.
• Only Phalcon\Events\ManagerInterface is supported. A custom manager that implements only Phalcon\Contracts\Events\Manager does not work with Subscriber::subscribe().
• Update docs/index.md:38, which says that the provider takes the MVC application. Add a non-MVC section that also shows a host with no events manager.
• Add a changelog entry.

Out of scope

• History. See [NFR]: Serve request history in ADR apps #43
• Data collection. Panels that need MVC events stay empty until [NFR]: ADR bridge and DataMapper database source #16, [NFR]: ADR route source #45, [NFR]: ADR view and cache panels #46 and [NFR]: ADR exceptions source #47.

Known limit

Phalcon\ADR\Application::handle() supports a reused request in a long-lived worker. Collectors have no reset method, so in a worker their data grows from request to request. HistoryCookie::fromGlobals() also reads only at boot. This issue supports one request for each process. Document this limit.

Acceptance

• The bar boots and injects into an HTML ResponseInterface in an application that has neither a Phalcon\Mvc\Application nor a Phalcon\Di\DiInterface.
• The bar is not injected into a JSON response.
• The bar does not boot in a blocked environment.
• The existing MVC integration (as used by phalcon/vokuro) is unchanged.
• Tests pass with full coverage. phpcs and phpstan pass.
• The documentation states the minimum versions, the provider order and the worker limit.

Depends on

• Slice 2 [NFR]: Extract a neutral boot core from Provider #40

Part of

#13