[Android] Avoid blocking the platform thread in PlatformViewAndroid::NotifyCreated and NotifyChanged #196180

In Shell::CreateWithSnapshot, we explicitly defer SetupImpellerContext() onto the raster thread to keep Vulkan initialization off the platform/UI thread during startup (shell.cc):

// Defer setting up the impeller context until after the startup blocking
// futures have completed. Context creation may be slow (100+ ms) when using
// the Vulkan backend on certain Android devices, so we intentionally try
// to move it off the critical path for startup.

But when the surface callbacks arrive, we still block the main thread in PlatformViewAndroid::NotifyCreated (and NotifyChanged) waiting for raster-thread work (platform_view_android.cc). That wait can include any remaining context initialization, other queued raster work, and surface setup.

Looking at Android's SurfaceHolder.Callback contract, only surfaceDestroyed is required to block on the render thread (surfaceDestroyed docs):

After returning from this call, you should no longer try to access this surface. If you have a rendering thread that directly accesses the surface, you must ensure that thread is no longer touching the Surface before returning from this function.

By contrast, surfaceCreated and surfaceChanged do not require a GPU swapchain to be attached before returning, and Android's graphics architecture docs explicitly recommend forwarding them asynchronously rather than blocking the UI thread (SurfaceView and Activity Lifecycle docs):

When using a SurfaceView, render the surface from a thread other than the main UI thread. [...] Instead, query or cache the surface state, and forward it to the renderer thread. [...] surface created/changed messages are forwarded.

I think we can change NotifyCreated and NotifyChanged here to be asynchronous:

• Prototype branch: master...gmackall:flutter:async-notify-created

Pretty before and after picture: