Prepare Routing for multi-domains / add extension points

[bwaidelich]

Extend the Router as follows:

1. Extend RouterInterface

As a first step we should change the RouterInterface from:

interface RouterInterface
{
    public function route(Request $httpRequest);

    public function resolve(array $routeValues): string
}

to sth like:

interface RouterInterface
{
    public function route(RouteContext $context): RouteResult

    public function resolve(ResolveContext $context): ResolveResult
}

• RouteContext contains some optional routeValues in addition to the current
• Http\Request (so that we can pre-set route values before the routing kicks in).
• RouteResult wraps the resolved routeValues and/or contains a flag whether a route matched at all.
• ResolveContext contains the routeValues in addition to the current Http\Request and (in v2) some flags like forceAbsoluteUrl, forceScheme
• ResolveResult contains the resolved Http\Uri and/or a flag whether a route resolved

2. Adjust Router Cache

The cache identifiers must be built from the RouteContext / ResolveContext (i.e. they should probably implement the CacheAwareInterface)

3. Allow hooking into RouteContext

I.e. it should be possible to write a Http\Component that can set routeValues for the current RouteContext (example: extract language from the Accept-Language HTTP header and set a routeValue correspondingly)

4. Allow hooking into ResolveResult

Introduce a signal that allows 3rd party code to hook into the ResolveResult just before it is put into the Cache. It should receive the ResolveContext and the current ResolveResult and might return a new result (or modify the existing one somehow)

To be discussed

• Do we need a b/c layer for the breaking Router(Interface) signature change?
• Are there better names for the new classes (see above)?

Background:

This will allow 3rd party packages (and Neos) to hook into the routing process and is a first step for a fully fledged multi-domain routing in Flow as described in #614

Neos: 3.3 LTS
Flow: 4.3 LTS

[bwaidelich]

Intermediate status

I managed to get a first version running (without adjusted tests & caching) that allows for custom RoutePart implementations to react to/influence parts of the URI "outside" of their respective route part.

I mostly followed the steps outlined above, with the following deviations:

2. Adjust Router Cache

.. I skipped that step (yet)

3. Allow hooking into RouteContext

Instead of hooking into the context via Http\Component, I created a signal Router::beforeRoute that allows to modify the context like this:

$dispatcher->connect(Router::class, 'beforeRoute', function(RouteContext &$routeContext) {
  // some check based on the current context, e.g. $routeContext->getHttpRequest()->getPort() === 8080
  $routeContext = $routeContext->withParameter('Some.Namespace', new Parameter('parameterName', 'parameterValue'));
});

There is no major advantage over a HTTP component, but I felt it was more in sync with the signal for the ResolveResult

Considerations

The impact of the change is not too bad, but the implementation feels a bit hacky and I think it make sense to abandon the Signal/Slot approach in favor of a more straight-forward implementation.

Recap

We need a way to set "route context parameters" before Router::route() is called because they affect the cache entry identifier (for example if the routing should react to some HTTP header of the request)

But we could maybe skip the whole "Url post-processing" by extending the RoutePart implementation to return some request.
Currently RoutePartInterface::resolves() should return a boolean (note: some implementations, Neos I'm looking at you, return a negative integer instead of false but we can cater for that).
I suggest to extend that so that RouteParts can return some object as well (instead of true) that contains "instructions" to apply on the final URL (for example forceScheme: https).

That way we can get rid of the need to post-process the ResolveResult and Router::resolve() can just return an instance of UriInterface that can be easily cached

[mficzel]

I removed this from the 3.3 project-board in favor of pr #1126 that fixes this issue.