Add support for laminas-httphandlerrunner v2.1

[Matthew Weier O'Phinney]

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	unsure

Summary

laminas/laminas-httphandlerrunner v2 was released earlier this year. The base mezzio/mezzio package can already utiliize it, and it is the version installed by default with a new Mezzio installation. This package should provide compatibility with it.

However, the new version makes a few changes that may make this difficult:

• It adds a RequestHandlerRunnerInterface.
• It marks the base RequestHandlerRunner implementation as final.

The problems are thus:

• In v1, there was no interface, so applications would pull the Laminas\HttpHandlerRunner\RequestHandlerRunner service from the container and use that. This package essentially overwrote that definition in order to provide an implementation.
• Also, because in v1 there was no interface, inheritance was the only way to provide a compatible implementation. Since v2 marks the default implementation as final, we cannot inherit in a version that supports v2.

I propose a minor + major release strategy:

• In the minor release, we provide multiple implementations:
  • A trait will define the full internals of each.
  • One implementation will target laminas-httphandlerrunner v1, extending the v1 version and using the trait; it will have the trait methods take precedence over inherited methods.
  • Another implementation will target laminas-httphandlerrunner v2, implementing the v2 interface and using the trait.
  • An autoloader will determine which one to use, and alias Mezzio\Swoole\SwooleRequestHandlerRunner to the implementation.
  • The ConfigProvider aliases the interface to the implementation.
• In the major release, one implementation:
  • The v2 implementation becomes the only implementation.

One other idea I've considered: vary what the ConfigProvider maps based on the laminas-httphandlerrunner version. Since we know the RequestHandlerRunnerInterface only exists in v2, we could simply define an additional v2-compatible implementation, and have the ConfigProvider map to its factory when detected, instead of the existing implementation. The main downside to this is if anybody was previously extending our implementation (which shouldn't be necessary anymore, due to the changes made to have it trigger events). We would still likely need a trait with the common functionality (required due to inheritance in v1), but it wouldn't require usage of class_alias().