Optimize alias lookup and load in PathFieldItemList

#2511968: Path field should fall back to language neutral aliases (also makes this happen for the form widget!) landed! Still blocked on #2336597: Convert path aliases to full featured entities.

> That would be very easy to do after #2336597: Convert path aliases to full featured entities since we'll be able to use an entity query with an OR condition on the langcode field

I disagree with that.

Path aliases being an entity or even stored in the database is an implementation detail, this is a pluggable interface, they could actually be stored in MongoDB, Redis or some other backend.

I think that means you disagree entirely with #2233595: Deprecate the custom path alias storage?

I didn't look at it yet in depth. The entity system itself is an abstraction too, so arguably, we are deprecating a custom storage system with a more general one, so that should be OK :) And we might to keep a limited API on top of that, because I would expect that an entity query + entity load is going to be several times slower than a simple SQL query that just fetches exactly the value that it needs. And there's actually a ton of additional cache logic on top of that with prefetching and what not, but I suppose that would remain.

I did something similar in redirect.module, which are also entities, I added a service/method (\Drupal\redirect\RedirectRepository::findMatchingRedirect) that bypasses the entity query API because that was *way* faster than an entity query. In that case, I still used a regular entity load on a match then, because performance for *that* isn't that relevant then, only the query that needs to run on *every* request was.

However, the alias system is different because having a result isn't the exception, for most sites its the default, so loading the alias needs to be as fast as possible as well. Not just that, we often do dozens of additional lookups on a patch to resolve aliases for all the URL's that we are generating and again expect lots of matches there too.

So my main point for that issue is that we spent *weeks* optimizing that as much as we could and we will have to be very, very careful to avoid performance regressions (or keep them to a minimum) in exchange for fancy features or simply removing code :)

And going back to this issue, using the entity query system directly would only be an option for 9.x as mentioned above.

#2336597: Convert path aliases to full featured entities is fixed, so back to Active (no patch)

🥳

This was fixed in #2233595: Deprecate the custom path alias storage where PathFieldItemList uses a single alias repository query in ::computeValue().