Support non string callbacks with lazy builders

I found at least three places where we need some tweaks to support non-string callbacks.

(This is just a proof of concept, feel free to bikeshed :)

Reading this issue again -- which I filed! -- I am wondering how I thought this would work with the way LB callbacks are stored in cached HTML...

But anyway, if it works, it works :D

About the patch -- I think that instead of repeating that code, we should add a method to the new callback resolver service, something like toString().

I'm thinking we should make clear that the string it generates is just for debugging purposes, something like CallableResolver::getDebugStringFromDefinition()?

It wouldn't be for debugging in this use case though -- it's to go in a lazy builder placeholder in the render cache.

No, these strings are only there for debugging purposes. The callable gets cached as serialized PHP.

Here's a new method to provide this functionality (my initial thinking was it could live in PlaceholderGenerator, but it is also related to CallableResolver so, either way works for me)

Fix typos

+++ b/core/lib/Drupal/Core/Render/PlaceholderGenerator.php
@@ -113,7 +114,7 @@ public function createPlaceholder(array $element) {
+    $callback = CallableResolver::getDebugStringFromDefinition($placeholder_render_array['#lazy_builder'][0]);

The callable resolver should be obtained as a service from the container.

> The callable gets cached as serialized PHP.

Where's the code that does that? I can't see that in PlaceholderGenerator. Does it happen earlier than that?

Where's the code that does that? I can't see that in PlaceholderGenerator. Does it happen earlier than that?

The render cache stores the whole array in the cache. And the cache backend (e.g. database backend) calls serialize() on that array. Thus a #lazy_builder callback can be an object method call, as long as the object can be serialized. And it cannot be a closure, which cannot be serialized.

The callable resolver should be obtained as a service from the container.

Is there some reason this is necessary? I don't think this service is overridable - there is no interface for it. Also the service doesn't need to be instantiated - only a static method is called on it. But we could obtain the service if there's a reason to.