[meta] Use Fibers for concurrency in core

Because the fiber doesn't actually run in parallel, I think we'd need the MySQL query to run async/non-blocking. So in the fiber, execute a non blocking query, suspend the fiber, get on with other stuff in the main thread, then go back to see if the query has come back.

Because with lazy builders we know what we're going to run before we actually run it, and they're self-contained, we ought to be able to make that work - but we'd have to build the async bits into the entity query API, views etc. to be able to do it.

MySQL's async support is only available with mysqli, not PDO. So we'd need... a mysqli database driver first. But it would allow us to do async things without forking.

Another very vague idea I had was file_scan_directory() and similar - i.e. when we're scanning and parsing files, doing the filesystem work in a Fiber using non blocking streams, and the CPU-intensive parsing outside it, interleaving the two instead of one then the other. But whether we'd actually see a measurable gain from that is hard to tell without trying.

@daffie let's take something like https://www.drupal.org/dashboard - there's four or five different views on there in blocks.

If you hit a completely cold cache, you have to execute all the views building those blocks, including both the listing query, then rendering the entities within them.

The idea being explored is that for each lazy builder - let's assume we're able to loop over them, you'd render it up until you have to run a views listing query. When it's time to run that query (or whatever appropriate point to delegate to the Fiber), it's done inside a Fiber with a non-blocking query. You then ::suspend() the Fiber and return to the main process, and start the next lazy builder, if that also has to run a views listing query, you'd also run it non blocking and ::suspend(), then you loop over all the lazy builders again to see if the various queries have come back, then render the results for anything that has, then continue polling until everything is rendered.

The page still can't finish rendering until the slowest query is finished, but if you have five slow queries that take 500ms each, then you might be able to run them all at once in the space of 600ms-1s instead of definitely having to run them sequentially in 2.5s. While you're running those simultaneous queries, you can also get on with PHP/CPU-intensive tasks like rendering - assuming we're able to arrange things so that these can be interleaved.

Fibers only allow us to paralellize i/o, not CPU, because there's not any parallel execution at all, so it has to be something like an async MySQL or SOLR query or http request to make any difference, and there has to be something to be getting on with while it's running - either more i/o or something else.

@daffie the link in #10 is back to this issue, which issue did you mean?

It looks to me like the work Matt Glaman has done in the blog post and the mysqli driver could meet in the middle.

Following on from #9:

1. Render bigpipe placeholders as (or in?) fibers.
1b. Add a mysqli driver with async support
2. Add support to views to execute the main listing query in ::execute() async, it would call Fiber::suspend() immediately after doing so.
3. When the fiber is resumed, views checks if its query has come back, and if so keeps going, if not ::suspend() again.
4. We could also do this outside views in PagerSelectExtender::query() specifically, where we execute two queries, both the count and the listing query, that gives us two places to Fiber::suspend() then.

It looks like Fiber::getCurrent() would be enough to tell if we're inside a Fiber or not, which would allow us to run the non-async code path for those cases, that way nothing changes.

Going to be some steps in the middle like dealing with

$result->setFetchMode(\PDO::FETCH_CLASS, 'Drupal\views\ResultRow');

in views query execution.

We also need a way to detect if the driver supports async queries and an API to execute them.

The view SQL query ::getConnection() method supports both replicas and a base_database setting on the view, this would allow sites to set up a separate async connection for mysqli leaving all other queries using the PDO driver. Would mean configuring each individual view as to whether it should use the async connection or not though. Or a site could switch to the mysqli driver for everything then it would just come down to whether we're executing inside a fiber or not.

Solr also supports async, so we could take a similar approach in search_api contrib too.

Re-titling now we actually require PHP 8.1

In slack @mglaman mentioned possibly using Fibers for post-response tasks. We'd need to find post-response things where we can actually use non-blocking APIs, but if we can that'd be a good idea.

I think Big Pipe + Views + mysql async is likely to be the most dramatic improvement here and also ironically simpler than some other options, since it's quite centralised, so have updated the issue summary with an outline of how it seems to be coming together.

Opened #3377570: Add PHP Fibers support to BigPipe.

Updated #3257725-12: Add a cache prewarm API with a more concrete proposal - no patch or anything but would be good to get more eyes on the idea. Let's add that tag yeah.