[google_maps_flutter] Adopts new async/await Swift Pigeon support - #12860

I assume this method can only be called on the main thread. Shouldn't this method be marked as @MainActor instead, or use MainActor.assumeIsolated in the implementation if that's not an option?

Same question for didTapCluster etc,. below.

Technically we don't know what thread this is called on, because calls that end up here start their life as a callback from the Google Maps SDK, and it doesn't seem to document it. Those calls do pass in a GMSMapView, and that's supposed to be main-thread-access-only, so I would certainly hope that they are coming in on the main thread, but we've never actually had any of the code assert that.

I think adding annotations everywhere is probably out of scope for this PR. It would probably be a good idea for someone to do a pass over the entire plugin (and really, all of our plugins) later and liberally sprinkle them with MainActor annotations so that all of the requirements that are currently implicit (e.g., all calls from the engine are coming on the main thread) are explicit. That will be complicated in the short term by the fact that the engine doesn't annotate its APIs yet, so plugins will need a bunch of assumeIsolateds everywhere the engine calls into them. For Maps, someone will need to decide whether we should assumeIsolated on the calls from the SDK given that it would be pretty weird for them to pass a main-thread object into a callback on a non-main thread, or explicitly dispatch to the main actor every time the SDK calls into the plugin.

(This did make me realize that I don't need all the @MainActor annotations on the tasks in these implementation methods though, because the code being awaited in the task already have the annotations, so I removed those.)

Also just want to double check that MapEventDelegate is not meant to be implemented by app code so it's fine for the delegate methods to be invoked asynchronously as long as the events are still fifo?

MapEventDelegate sends platform messages (under the current implementation) via Pigeon to the Dart side of the app's codebase, so that events can be handled there. But those have always been async once they hit the engine since that's how the platform channel system works.

I'm a bit surprised that we don't need the explicit self capture here with Task, what changed?

See this reply to the Gemini review; I realized that the weak self was adding complication without any actual benefit. And we don't need an explicit capture for a non-weak self because Task is considered low-risk for leaks (since they aren't owned persistently like a general lambda), so there's no warning about not being explicit.