Fix loadedCallbackPending logic to properly prevent frame invalidation during Unity player creation

[dev-aman]

Description

Problem

The loadedCallbackPending variable was not being properly managed, causing potential race conditions and unnecessary frame invalidation calls during Unity player initialization. The guard condition in invalidateFrameIfNeeded() was ineffective because:
The variable was never being set to true and also it resets to false immediately after the guard check instead of when the callback actually completed.
This could lead to frame invalidation attempts while Unity player creation was still in progress

Solution

• Properly set loadedCallbackPending = true when Unity player creation begins
• Reset loadedCallbackPending = false only when the OnCreateUnityViewCallback.onReady() is called or on error
• Remove the incorrect reset in invalidateFrameIfNeeded() method

Related Issues

Fixes potential race conditions during Unity player initialization that could cause rendering issues or crashes.

Type of Change

• ✨ New feature (non-breaking change which adds functionality)
• 🛠️ Bug fix (non-breaking change which fixes an issue)
• ❌ Breaking change (fix or feature that would cause existing functionality to change)
• 🧹 Code refactor
• ✅ Build configuration change
• 📝 Documentation
• 🗑️ Chore

[timbotimbo]

Hmm, this is a workaround for a bug introduced in Flutter 3.0 and I wonder if it is still needed at all.

Out of curiosity, did you run into a bug or performance issue that made you look into this? Or did you simply spot something weird in the source code?

Some context.

• Before 3.0 Flutter had 2 platform view modes: Hybrid Composition HC) and Virtual Display (VD).
  The useAndroidViewSurface param in this plugin toggles between the two, with VD being the default.

• Flutter 3.0 replaced VD with a new mode (TLHC), which broke on SurfaceViews like Unity is using.
  This plugin temporarily switched the default to HC to avoid being fully broken (plugin v2022.1.1).
  (The google maps plugin changed their default too).

• This workaround was added in google_maps_flutter to fix some issues caused by TLHC.
  And it looks like a variant of that was added to this plugin.

• Flutter 3.3 added a TLHC -> VD fallback when using a SurfaceView, so this plugin returned to the old behaviour.
  Plugin version 2022.2.0 switched the default back to VD because the Flutter 3.3 fix worked.

There's a chance that this workaround (if it works at all) is redundant after Flutter 3.3.