[platform_view] Remove the views from composition_order if they are being disposed

[cyanglaz]

DisposeView happens every frame before laying out PlatformViews, with the order specified in composition_order_. Because view_to_dispose_ is determined on UI thread and composition_order_ is determined on the platform thread, there could be a race if the dart code on the UI thread runs faster than the rasterizer on the Platform thread, causing a view in view_to_dispose_ is still in the composition_order_.

When this happens, we should delay the views in the composition_order_ being disposed and wait for the next frame to dispose them.

fixes flutter/flutter#125223

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[hellohuanlin]

I may need some help understanding the logic of what these fields are for, but first of all, DisposeViews() is called in main thread (from the FML_DCHECK), is it ok to directly modify composition_order_ (which is also updated in raster thread, described in github issue)? Does the caller of DisposeViews() already guarantee the thread safety?

Maybe im missing something. let me know if you wanna sync.

[cyanglaz]

Oh actually, composition_order_ is updated on the main thread. The raster thread and main thread are merged. I need to clarify it in the issue.

[saintmac-google]

Tested on our app, it works fine :)

[cyanglaz]

Closing in favor of #41521