Upgrade Service Manager to v4

[simon-mundy]

Q	A
Documentation	no
Bugfix	yes
BC Break	yes
New Feature	no
RFC	no
QA	yes

Description

This PR addresses issues #75 and #76 and seeks to modernise the codebase for a 4.0.x release.

The existing Filter and View components have been used as guidance, and I have been
aggressive in seeking better psalm compliance, refactoring of code and tests and
removing outdated/deprecated code.

Breaking Changes

• Requires laminas-servicemanager ^4.0
• Removed Wildcard route
• Route classes now use strict typing for all parameters
• Attempted to use Interfaces to type as much as possible instead of static

RoutePluginManager

• Refactored with CONFIGURATION constant for default routes
• Routes must be explicitly registered or use invokables config

Route Classes

• All route classes use final modifier where applicable
• Constructor property promotion throughout
• Added RoutePriorityTrait for consistent priority handling
• Added RouteConfigTrait for standardized option processing and iterator conversion
• setPriority()/getPriority() added to RouteInterface

Code Quality

• Factories marked as final readonly
• Exception classes marked as final
• Superceded ArrayUtils::iteratorToArray() with trait-based implementation

NOTES

• Unsure as to how to introduce i18n testing - TranslatorInterface used sparingly for now

[simon-mundy]

Well... I had some time to experiment today so I took and idea and ran with it. Even if we don't end up using this, it was worth the time to better understand the component.

So I ended up separating the PriorityList $routes in the Stacks, renamed them to RouteContainer for clarity, then created a base Interface, and extended Interfaces for SimpleRouteStack and for HttpRouteStack so that subsequently each Route type ends up with a properly-suited RouteInterface (both the RouteMatch and RouteInterfaces both had very http-specific differences).

Now this is fully refactored to use PSR-7 requests, and I could remove dependencies - except Laminas\Uri which we need to help assemble routes.

I understand this is now a bigger concern in terms of a PR, but as a I said I'm happy to pull back a bit and re-release in sections if that helps us understand how best to approach this.

[gsteel]

@simon-mundy Sorry I was just about to review, but I merged #95 so a rebase is needed here.

I'm also likely going to merge #92 which will get merged up into 4.0.x once released, so maybe hold off until that's in so rebase is only needed once.

[gsteel]

#92 is now released and merged-up

[simon-mundy]

Thanks @gsteel I've rolled in that change to my PR and it's clearer to see where it sits.

[simon-mundy]

Hi @gsteel @froschdesign did you want to discuss any of the code improvements?

[fezfez]

@simon-mundy imo you could split your pr in multiple one, the review would be easier and your work could be merged faster

• add strict type
• code quality
• add sm v4
• fix deprecated property $prority

[simon-mundy]

@fezfez I haven't split these before - do I create individual PRs for this? For each item you've listed? It may or may not be easy to separate everything but I'll see what I can do.