block-preview: reduce computing delay to zero

[retrofox]

Description

This PR reduces the delay applied before to start to compute the scale for the preview, from 100ms to 0. This delay is needed to required to account for async render of BlockEditorProvider, but it seems to be enough just a 0ms after the component is mount.

How has this been tested?

TBD

[youknowriad]

In #17493 we noticed some bugs when the images are not loaded quickly (the height is not adapted properly).

I think we should remove that timeout entirely and find a way to be reactive instead. Recompute when needed. I'm not sure how technically feasible is that though.

[retrofox]

Yes, I was mostly testing and trying to research the real reason why it fails inconsistently. However, it seems to be a hard bone to crack.

...some bugs when the images are not loaded quickly.

I'm not sure it's a reason, though. We've been working on previewing many blocks, with many inner blocks, with many (slightly weight) images on them and images don't seem to be a problem.

Going to test deeply to bring a better idea about where it fails.

In the meanwhile, What do you think about to be able to set the delay through a block property? 301aed5

[youknowriad]

In the meanwhile, What do you think about to be able to set the delay through a block property? 301aed5

These are all good options, or maybe instead of a delay, setting an interval to refresh... I think we need to explore options and check the best one for all use-cases.

[retrofox]

For instance, the below shows where preview works as expected (green squares), and where it fails(the red one) to set a timeout of 0ms. There aren't images there, and it's a super simple block in terms of processing

[Mamaduka]

@retrofox, I think we can close this one as well. This code is no longer in the core, and the scale is now calculated using useResizeObserver.

P.S. Sorry for the pings; I'm going through the old PRs and trying to see if we can move them forward or close them.