Decouple the router.request_context service from the request service.

Reroll after #1316692: Convert hook_admin_paths() into declarative properties on routes. How do we educate devs to use request stack service instead of request service in new code?

Supposedly the test failures are a result of working with the url generator lacking an appropriate request object in the parent site. As a consequence the global url function might produce different results for the parent site and the child site.

Therefore it may be necessary to setup the request stack in the simpletest parent site, such that a proper request is available through the request_stack service.

The natural place to inject the request-context into the test-container would be either TestBase::rebuildContainer or WebTestBase::prepareRequestForGenerator. However none of them works because further down in setUp we're calling drupal_flush_all_caches and that one ends up in DrupalKernel::boot(). In fact DrupalKernel::updateModules() reboots the kernel for the reason stated in the following comment:

    // If we haven't yet booted, we don't need to do anything: the new module
    // list will take effect when boot() is called. If we have already booted,
    // then reboot in order to refresh the serviceProvider list and container.

core/lib/Drupal/Core/DrupalKernel.php.Drupal\Core\DrupalKernel->initializeContainer() : lineno 379	
core/lib/Drupal/Core/DrupalKernel.php.Drupal\Core\DrupalKernel->boot() : lineno 177	
core/lib/Drupal/Core/DrupalKernel.php.Drupal\Core\DrupalKernel->updateModules() : lineno 338	
core/includes/common.inc.drupal_flush_all_caches() : lineno 4937	
core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.php.Drupal\simpletest\WebTestBase->resetAll() : lineno 1029	
core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.php.Drupal\simpletest\WebTestBase->setUp() : lineno 872	
core/modules/taxonomy/lib/Drupal/taxonomy/Tests/TaxonomyTestBase.php.Drupal\taxonomy\Tests\TaxonomyTestBase->setUp() : lineno 26	
core/modules/taxonomy/lib/Drupal/taxonomy/Tests/TokenReplaceTest.php.Drupal\taxonomy\Tests\TokenReplaceTest->setUp() : lineno 28	
core/modules/simpletest/lib/Drupal/simpletest/TestBase.php.Drupal\simpletest\TestBase->run() : lineno 858	
[...]

The reason why the $request service is not affected, is that the kernel takes care of restoring it when rebuilding the container. We probably need to do the same for request-context.

I think that the proper way to resolve the problem would be to delay booting the kernel until after WebTestBase::resetAll. However, that does not seem practical given that a lot of services are accessed throughout WebTestBase::setUp.

Let's try that.

@dawehner questions the hunk in WebTestBase::prepareRequestForGenerator. Let's see whether we can live without it.

Get rid of custom persist logic for the router.request_context</service>. The custom logic actually is only required for the <code>request service because it potentially is scoped.

Persisting router.request_context service actually is necessary because the reasons given in #6: In short we end up with an empty request context and that will affect the URL generator (and thus the url function) in the simpletest parent.

The change to Symfony\Cmf\Component\Routing\ProviderBasedGenerator was accidental. Lets revert that and at the same time revert the changes to the Drupal\Core\Routing\UrlGenerator to restore consistency with CMF.

Silly me, failed to add the '@'-character to one of the container service references.

Reroll, no changes.

Reroll after #2229223: RequestStack is not persisted across kernel rebuilds

Is there a reason for this change?

Upon closer inspection the change to the url generator service definition does not seem to be strictly required as part of this patch. Let's try and revert that change.

Does that mean that the router listener ensures that?

Exactly. In 2.3 mode, the request stack is not injected into the router listener. The router listener therefore cannot possibly update the request context by itself. Whereas in 2.4 mode the router listener does maintain the request context from within a KernelEvents::REQUEST handler. (see RouterListener::onKernelRequest()). In the simpletest parent site we still need to update the request context manually. Before this was done upon synchronization of the request service - i.e. whenever something called \Drupal::service('request')->set(...).

Uh, no test results, let's trigger a test-run.

20: 2223593-use-request-stack-in-router-20.diff queued for re-testing.

This looks like a testbot failure. Retest and back to RTBC.

Reroll.