Combine the database queries in ::loadFromSharedTables() and ::loadFromDedicatedTables()

Let's do #3564689: Combine multiple cardinality field loading into a single database query first.

Pushed an initial MR here (was an empty issue fork before, think I hit the button by mistake).

This is non-trivial to get right because of the various combinations of base/revision/data tables that entities may or may not have along with whether we're loading revisions or not. However I'm down to a handful of test failures in core's kernel entity tests so worth seeing what else breaks.

A bit closer - all green on kernel tests although I get one content_moderation kernel test failure locally.

Performance tests are failing in the right way, but won't update those until everything else is passing in case the queries need to change again.

Haven't looked at the functional test failures yet.

OK we're green now.

The MR is stacked on #3576129: Reduce calls to FieldDefinition::getColumns() which is RTBC, so marking PP-1 but also needs review because it would nice to get some high level reviews.

This removes a query from pretty much every entity load. It's less than the previous two issues it was postponed on, but it's also a similar-ish percentage of some requests because we've removed so many other queries now - e.g. 5-10% of database queries in various scenarios, higher percentages in the 'cool cache' cases.

The diff is quite big partly due to the stacked MR, but also partly because it removes an if statement when loading single cardinality fields, since we always do run that query now to get the base fields.

The tricky thing is the langcode handling, we have to handle both revision and non-revision queries in the same place, and the base table langcode logic is slightly different from the dedicated tables langcode logic, due to things like revisions and translations being added, removed etc. It's not dramatically more complex than the logic it's replacing but it was hard to get right because there's so many combinations with different entity schemas.

Not very happy with how long ::loadFromDedicatedTables() is becoming, maybe we can find some logic to move to helper methods.

Had to add a new parameter to ::loadFromDedicatedTables(), we might need to search contrib just to check that never actually gets called or overriden anywhere, doubt it does tbh.

We also need to decide if we're going to rename loadFromDedicatedTables() and also whether we do it in this issue or not.

Postgres and sqlite are green but MariaDb is unfortunately not https://git.drupalcode.org/project/drupal/-/jobs/8948781 - I saw this failure once or twice on my local but didn't realise it wasn't fixed by changes that fixed other tests.

This is another symptom of:

The tricky thing is the langcode handling, we have to handle both revision and non-revision queries in the same place, and the base table langcode logic is slightly different from the dedicated tables langcode logic, due to things like revisions and translations being added, removed etc. It's not dramatically more complex than the logic it's replacing but it was hard to get right because there's so many combinations with different entity schemas.

Fixed the last remaining test failure and the blocker is in.

Added the ::loadFromSharedTables() deprecation.

Tagging for release highlights. Along with #3564689: Combine multiple cardinality field loading into a single database query and #3551308: Combine single cardinality fields into a single database query when loading entities this is worth its own sentence.

I checked usages:

https://search.tresbien.tech/search?q=loadFromDedicatedTables%20-f%3Acor...

https://search.tresbien.tech/search?q=loadFromSharedTables%20-f%3Acore&n...

Looking at the actual file: https://git.drupalcode.org/project/civicrm_entity/-/blob/4.0.x/src/CiviE... - this is a complete re-implementation of the storage with the same method name, no override, and it's called from another method in that class.

So there are zero usages in contrib, seems even less likely there is custom code around this for this particular change.

Part of the reason I didn't rename the method yet apart from laziness is not having great ideas. We could do loadFromTables maybe? Or loadFieldRecords ? But I'm not sure these are dramatically better than ::loadFromDedicatedTables()

I think if we rename, we also need to decide whether the old method will call the new one with the new code, or whether to restore the old code to it, which would be deprecated dead code then. Given the zero usages this probably doesn't matter in practice.

Switching the CR tag to needs CR updates since I think we can update https://www.drupal.org/node/3562172 to cover all three issues - at least as long as this gets into 11.4 (which would be great considering how closely linked the changes are, and it'll be much easier to talk about the performance improvement).

Arghh I forgot all my previous arguments and ended up opening a separate CR. But now having written it, the previous CR was practical information for site owners instead they suddenly run into OOM https://www.drupal.org/node/3562172 and the new CR for a deprecation of a method we're pretty sure no-one is overriding or calling. So... that is probably fine, moving back to needs review.

Also had to rebase for performance test changes.

Rebased.

Had to fight both myself and gitlab but back to green. Ridiculous amount of MR activity for what is one alias rename but since that's all it actually is, moving back to RTBC.

Backport MR is up - only query counts in performance tests differed.