Change default resource locations for functions

[wandamora]

This updates the default resource location for various functions from us-central1. This should only impact NEW functions, not the location of existing functions. The exhaustive list includes:

• New event functions match the resource of their event source. (Firestore, Cloud Storage, Firebase Realtime Database, Firebase Data Connect)
• If a Firestore bucket is in a multi-region, then nam5 & nam7 -> us-central1, and eur3 -> europe-west1
• If a Cloud storage bucket is in a multi-region, then
  • “us” -> us-east1
  • “eu” -> “europe-west1”
  • “asia” -> asia-east1
• Auth blocking functions (beforeCreateUser, beforeUserSignIn) and Global AI Logic blocking functions (beforeGenerateContent, afterGenerateContent) are set to us-east1.
• Remaining global event functions (Pub/Sub, Firebase Auth/GCIP, Firebase Test Lab, Firebase Remote Config, Firebase Alerts) are set to us-east1

[gemini-code-assist]

Code Review

This pull request implements dynamic region resolution for Cloud Functions, moving away from the hardcoded us-central1 default. It introduces logic to determine the optimal region based on trigger types and the location of associated resources like Firestore databases, Storage buckets, and Realtime Database instances. Feedback focuses on performance optimizations, specifically recommending parallelizing asynchronous resource lookups using Promise.all and implementing caching for Storage and Realtime Database metadata to avoid redundant API calls. Additionally, it was suggested to map multi-regional locations like nam5 to us-east1 to better distribute the load.

[ajperel]

I think we talked yesterday about maybe this code could be simplified to rather than checking event type just check if the target region is global and if so target us-east1. That could be robust to new global things not accidentally defaulting to us-central1

Do you think that would work? Better or not?

[ajperel]

We have location resolution logic throughout all this code. It does match the design. But, taking a step back... I think we are always suggesting the a single mapping from (multi-region) to region. It just so happens that a bunch of regions don't matter for each event type.

Do you think it'd be clearer to have something like

getFunctionRegionFromEventSourceRegion() {
    // global case
    // multi-region cases (nam5, etc.)
    // multi-regional cases (us, eu, asia)
    // single region default (return the region)
}

Then it's basically "If you're in scope to go near the default we call this one function to do the mapping" and if you're not in scope to move you fall through to the old default of us-central1.

This would only break down if we were resolved differently for different event types, e.g., Firestore triggers in nam5 resolve to a different region than Cloud Storage. I have no idea if that would ever happen?

I think the flip side argument to this is that some of these regions actually only really make sense for specific services and we're sort of conflating all that.

I'm not 100% sold on my suggestion so curious your thoughts.

[ajperel]

Should we be doing anything for non-global AI logic endpoints?