Remove DrupalKernel::initializeRequestGlobals and replace base_root, base_url and base_path with a service

MR meeds rebase

Tried rebase via the merge request GUI, it fails. Feb 23 status looks green from the above comment description but I don't see the job, not sure where to find it.

Changed properties and fixed last usage, token changes looks like needs discussion

The testbot is not happy

The issue appears on the Drupal\Tests\Core\Command\QuickStartTest run. It probably blocks the rest of the functional tests.
Any idea what is the cause of that behavior?

I guess it means that functional tests does not get request properly so url is not extracted, it reminds me somehow 📌 Add the session to the request in KernelTestBase, BrowserTestBase, and drush Fixed

📌 Add the session to the request in KernelTestBase, BrowserTestBase, and drush Fixed looks great, let's wait when it will be fixed.

quietone → credited afedoruk → .

quietone → credited dileepmaurya → .

quietone → credited izus → .

Closed 📌 Remove LanguageNegotiationUrl's usage of base_path() Closed: duplicate as a duplicate, adding credit.

I updated the PR, and I'm not sure why the `app` service was not initialized in most cases.

I've been working on trying to figure out how to move Drupal to a place where it might be able to handle multiple requests in a single process as part of #2218651: [meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP, Swoole → and 🌱 Adopt the Revolt event loop for async task orchestration Active . While doing this I've been looking at how the Symfony Runtime works which has already been requested for adoption in ✨ Use symfony/runtime for less bespoke bootstrap/compatibility with varied runtime environments Active . With that background I've been looking at this issue (since global state is problematic).

If I look at the proposed app service, then it doesn't really work until `setRequest` is called, which shows that up until the DrupalKernel has bootstrapped, as a service, it doesn't work within the container. We can also see in the proposed MR that there's a hidden dependency of App on a Request in our tests, even though those tests might be testing components which should be independent of a request. That highlights an architectural issue.

Tangentially, the name App is somewhat confusing because it has overlap with the concept of "Application" which could be something like Drush.

With those things in mind I would like to propose a change in solution direction:

- The App class should be an AppContextInterface which is pulled out of DrupalKernel.
- The class AppContext is added with most of the code of the proposed App class which is the only implementer of AppContextInterface in Drupal
- AppContextInterface and AppContext are extended from the proposal to include getAppRoot which replaces the function of the same name on the kernel.
- The $app_root argument on the DrupalKernel constructor is replaced by an AppContextInterface instance (some type checking and backwards compatibility work would be needed to manually instantiate this if not provided).
- Front-end controllers like index.php are updated to create AppContext from the request which is already present there and pass it to the kernel.

Performing the change in that way makes the path configurations part of the runtime, rather than the kernel. This makes it easier for non-request based applications like Drush to create their own context implementation.

Making and maintaining these kinds of changes in the index.php, install.php, update.php, and reload.php at the same time may be somewhat cumbersome. This is exactly what the Symfony Runtime component tries to solve (with a few of those responsibilities now included in the DrupalKernel).

Great idea to turn app into context! btw the real problem here is the Request object which could be any flavor (Symfony, Swoole, PSR, ...) so runtime or frontend controller must care about converting incoming request into consumable by core

I've been playing with this issue (and some related things) all day and I've come to the conclusion that this (and a few other things) become about 100x easier if we adopt Symfony's Runtime component because it provides a clear separation of responsibilities for the "Runtime" and the "Request handling" (Kernel).

Since I'm actively working on ✨ Use symfony/runtime for less bespoke bootstrap/compatibility with varied runtime environments Active to make that happen (it exactly solves the issue described by Andy in #105) I'm marking this as postponed on that.