Performance regression caused by using the last installed entity definitions

Related improvement that helps to reduce the impact of this: #3162827: Do not instantiate entity storages in constructors of services that do not always need them

What about something like this, which is consistent with how entity type/field manager cache those things. A single cache entry for all entity types and a cache entry for the field storage definitions per entity type, as they can be quite big:

> select name, length(value) as length from key_value where collection = 'entity.definitions.installed' order by length desc;
+----------------------------------------------------+--------+
| name                                               | length |
+----------------------------------------------------+--------+
| node.field_storage_definitions                     |  60272 |
| media.field_storage_definitions                    |  53352 |
| paragraph.field_storage_definitions                |  40090 |
| menu_link_content.field_storage_definitions        |  29116 |
| taxonomy_term.field_storage_definitions            |  26073 |
| block_content.field_storage_definitions            |  22656 |
| webform_submission.field_storage_definitions       |  22110 |
| crop.field_storage_definitions                     |  21423 |
| user.field_storage_definitions                     |  21009 |
| paragraphs_library_item.field_storage_definitions  |  20169 |
| content_moderation_state.field_storage_definitions |  16169 |
| file.field_storage_definitions                     |  12357 |
| redirect.field_storage_definitions                 |  11918 |
| shortcut.field_storage_definitions                 |  10084 |
| path_alias.field_storage_definitions               |   9528 |
| monitoring_sensor_result.field_storage_definitions |   8888 |
| webform.entity_type                                |   5921 |
| paragraphs_library_item.entity_type                |   4979 |
| webform_submission.entity_type                     |   4956 |
| search_api_index.entity_type                       |   4948 |
...

Also using the discovery bin, just like those services.

For some reason that I don't know, we don't inject the service into entity field manager but query the key value storage directly, so I have to fix that.

Also, in case someone does writes directly to key value, it will skip cache invalidation, but there's not much to be done about that.

Lets see how well this works. I did manual testing on a standard install and it saved 10 key value queries for me. And cache lookups should be minimal due to fast chained.

Fixing the test fails. Workspace test needs an updated container, fixed one bug to unset the statically cached entity type definitions when one is deleted and updated the unit test.

Coding standard fix.

#10 profile shows +8 calls to getLastInstalledDefinition

OIwait +713% 0.8 µs → 6.5 µs

Thanks for testing. IMHO queries/s is more likely to be the bottleneck of a site.

For context, this patch + #2575105: Use cache collector for state meant that one of the large NP8 sites went from 8k key_value queries per minute (that's 130/s) to 400 per minute. I don't have data on memory usage, apparently new relic doesn't collect that.

@andypost: anything that says "µs" is well within random variations, you can also see that database queries are 500µs slower but it's the same queries, that's perfectly fine and normal. The first profile is also 1.5% slower, but again, that's mostly just random variations.

Note: the node edit profile link doesn't seem to work.

All code changes look good to me.
The patch adds the use of a backend cache to the entity.last_installed_schema.repository service.
There is already a lot of testing for this service and to me that would fail if the added backend cache was not implemented correctly.
@alexpott adds performance profiling results that show that the patch is saving in the number queries. It also shows that the memory usage is a little bit higher, from 12.5MB to 13MB. To me almost any performance increase outweighs a memory usage increase.
In comment #12 @Berdir confirms that the patch from this issue in combination with the patch from #2575105: Use cache collector for state makes the number of queries to the key_value table decrease from 8000 per minute to 400 per minute.
I have added a CR for the new construction parameters to the classes EntityFieldManager and EntityLastInstalledSchemaRepository.
This is for me enough to give this issue a RTBC.

This looks great and the numbers look good.

Committed 685419f and pushed to 9.2.x. Thanks!

I'm leaving this fixed on 9.2.x rather than backporting due to the various constructor changes.

Published https://www.drupal.org/node/3190792.