Make service closures serializable in classes using DependencySerializationTrait

Added a CR.

Gave the service closure class a shot on MR 13575.

Re #10: I thought about this when working on the MR, and I think we're introducing an interesting DX quirk. The way I see it, the new class would only be used in plugins implementing ContainerFactoryPluginInterface or other classes implement ContainerInjectionInterface. So for now, it'd just be the search block we're working on in #3544405: [PP-1] Replace SearchBlock service properties with service closures. We can also make AutowireTrait use the ServiceClosure class instead of \Closure in #3554337: [PP-1] Support the AutowireServiceClosure attribute in AutowireTrait to inject service closures.

Services would continue to use the Symfony code that injects \Closures, and I think that's fine-ish? Are there cases where services themselves are being serialized? If so, maybe it'd be necessary to override how service closures are injected and use the ServiceClosure class in the Drupal container classes or compiler passes, but that sounds a bit complicated. But if we don't, it'd be on developers to keep track that \Closures are being passed in to service arguments and ServiceClosures are passed into plugins, etc., which is the DX quirk I mentioned.

Because of above, I'm not sure which approach is better. How service \Closures would be identified in DependencySerializationTrait has its drawbacks as mentioned in #6.

An alternative that I just thought of how to identify service closures with DependencySerializationTrait would be to require an attribute to be applied to any constructor argument that is a service closure. For classes that are autowired, we could use AutowireServiceClosure, and maybe that's fine to use even if classes implement their own create() method? Then on serialization, we'd use reflection to identify which the property name and their service IDs.

OK, so I realized #12 isn't great, because constructor parameters aren't class properties unless the class is using property promotion.

I do have another idea, though, basically adding a method in DependencySerializationTrait that generates the closure with an attribute. Then in __sleep, check whether the closure has the attribute. It'll be easier to explain after I have a POC, which I think I can knock out later tonight.

OK, MR 13584 has a POC of the approach I mentioned in #14. The idea is:

1. Introduce Drupal\Core\DependencyInjection\Attribute\ServiceClosureclass that can be applied to functions/closures
2. Create a new static method getServiceClosure(serviceId, container): Closure on DependencySerializationTrait that returns a closure that returns the service associated with the service ID. The attribute is applied to the closure
3. Use spl_object_id() on the closure to create a key in a static array in DependencySerializationTrait that maps to the service ID. So basically there is a map of a unique ID for the closure to the service ID, and this is done so we don't have to invoke the closure to see what it returns in __sleep
4. In __sleep(), loop through all the properties that are closures, and check for the ServiceClosure attribute. For every closure that has the attribute loop up the service ID associated with the closure's unique ID in the map, then track which properties map to which service IDs as closures. Unset the entry in the closure ID to service ID map
5. On __wakeup, repopulate the closure properties using getServiceClosure()

Yes, originally I tried having a separate trait that both AutowireTrait and DependencySerializationTrait could both use, but then there were complications about where the tracking array would live, and then if a class used both AutowireTrait and DependencySerializationTrait, I think there might be a conflict with the method being declared twice.

I think in the AutowireTrait issue, we can do something like if (method_exists(static::class, 'getServiceClosure') { ... }. It might be best to rename the method to getSerializableServiceClosure() in that case, so it's less generic and less likely that a different method with the same name exists in the class.

If there are plugins, forms, or controllers that would never be serialized, then technically they wouldn't need to use the method, and if they do need to be serialized they likely would need to use the trait to make serialization safe for their service properties anyway, so I think that works out OK.

I was thinking of relying on the search block, but there's probably a lot of value in finding a form class or something that actually gets serialized, so I'll see if I can find a suitable one.

It occurs to me that since there's a lookup map for closures to service IDs, we don't technically need the ServiceClosure attribute. (My original idea was to pass the service ID into the attribute, but that's not possible since attribute parameters can only be constant expression.)

On the other hand, the lookup map is the part of the solution I like the least. And maybe in _sleep() there should be a fallback where any closure that has the attribute but isn't in the lookup map somehow that the closure gets invoked and then the service ID can be looked up from the reverse container.

Updated a couple form classes to use the new service closure method to test how they worked. It occurs to me that form classes might not be the best use case for service closures, since anywhere the form class is loaded likely will call the form processing code that uses the services, but I thought a form with AJAX might be the best demonstration of the class being serialized. I meant to do only one form to start (esponsiveImageStyleForm), but I noticed there are no FunctionalJavascript tests for that form, so I added another.

I did not do the fallback thing I mentioned in #20, and also left the attribute in place.

OK, did the fallback thing after all. So even if someone creates a closure without getSerializableServiceClosure(), as long as they put the ServiceClosure attribute on it, DependencySerializationTrait will handle it. People should definitely use the method if they can though, because that saves an unnecessary instantiation of the service just to make the class serializable.

Also added a bit more test coverage.

It occurs to me that a different way to do this could be to set an attribute on the class properties that are service closures. For example:

class ExampleForm extends FormBase {

  #[ServiceClosure('entity_type.manager')]
  protected EntityTypeManagerInterface $entityTypeManager;

}

Then, in __sleep(), any property that has the attribute gets set to NULL. In __wakeup(), we'd use reflection on the properties to pick up the service ID and recreate the closure.

There is some weirdness to deal with if we do #3554337: [PP-1] Support the AutowireServiceClosure attribute in AutowireTrait to inject service closures as well, because without property promotion, we'd have:

class ExampleForm extends FormBase {

  #[ServiceClosure('entity_type.manager')]
  protected EntityTypeManagerInterface $entityTypeManager;

  public function __construct(
    #[AutowireServiceClosure('entity_type.manager')
    EntityTypeManagerInterface $entityTypeManager,
  ) {
    $this->entityTypeManager = $entityTypeManager;
  }

}

Or with property promotion, something perhaps even stranger looking:

class ExampleForm extends FormBase {

  public function __construct(
    #[ServiceClosure('entity_type.manager')]
    #[AutowireServiceClosure('entity_type.manager')
    protected readonly EntityTypeManagerInterface $entityTypeManager,
  ) {}

}

This would be necessary since AutowireServiceClosure only targets parameters, and not properties, and what I've read, we wouldn't be able to reflect a property to get the attribute.

One way to get around that would be to have a Drupal ServiceClosure attribute class extend the Symfony AutowireServiceClosure and make it target both property and parameters.

Implemented what I mentioned in #27 in MR 13997. I think this is a lot cleaner, and will be even more so once #3554337: [PP-1] Support the AutowireServiceClosure attribute in AutowireTrait to inject service closures is in. Will update IS and CR tomorrow.

IS and CR updated to reflect MR 13997.