Improve caching around SchedulerManager::getPlugins() and SchedulerManager::getEntityFormIds()

As an additional improvement, I'd add a check to scheduler_form_alter() to see if this is even an entity form ($form_state->getFormObject() instanceof EntityFormInterface, at least for the methods that expect it.

I see this was already improved recently in #3533739: Implement static caching around SchedulerManager::getPlugins() but I'd go further and remove the persistent cache completely.

Created a merge request with some suggestions.

With the change in the other issue, it's better, but it still shows up in blackfire. Converting to only a property, getPlugins() no longer shows up at all, and by converting getEntityFormIds() to fast chained cache, scheduler_form_alter() is now no longer visible in blackfire as well.

Additionally, I changed the getTypes() call to using the bundle info service, that's faster (loading all config entities just to get their ids is very expensive), and it would also work for entity types that don't use bundle config entities. That could also be skipped for this issue, didn't do DI and so on.

Will need to check the failing tests.

This should help with the tests, I had misremembered the cache tag that's used for the bundle info. Also added tests for he other one.

The use of the entity type bundle info service should enable considerable simplification in SchedulerPluginBase. It will always return a default bundle, so the whole $isBundle stuff can go. getTypes() is unused now. Not new, but it makes no sense that $entity_type is passed to entityFormIdsByType() because it's already available as the plugin is for a specific entity type (update, I see it's for the bundle entity type that's passed, still pretty confusing and at least the is bundle part can be dropped). The protected properties in \Drupal\scheduler\SchedulerPluginBase::entityTypeFormIds and \Drupal\scheduler\SchedulerPluginBase::entityFormIds() are likely pointless as well now, there are no direct calls to these methods. But all that could be a follow-up and some of it is tricky with BC if you care about that for child plugin classes.

I agree. Part of the cleanup would be possible without BC breaks, but I don't know your exact approach on things like removing properties, arguments and methods in a plugin base class. so it's probably easier to do that refactoring, which will not have a performance impact, in a separate issue.

I was able to work on this partially in scope of a performance assessment on a client site, any further work would need to happen outside of that I can't say if and when I'll be able to do that.

It would also be very nice to have the already done improvement and this in a release, it's currently hard to apply those changes as patches due to larger changes.