[demolaf]

Adds an internal client for the Identity Toolkit v2/passwordPolicy endpoint, the one the JS SDK's validatePassword() uses, plus an evaluator for its requirements. Nothing calls it yet.

Changes

• PasswordPolicyRepository fetches with HttpURLConnection and org.json (no new dependencies), sends X-Android-Package and X-Android-Cert, adds tenantId when set, and caches per app and tenant.
• Every failure (offline, timeout, any non-2xx including the Auth emulator's 501, bad JSON, a schemaVersion other than 1) returns no policy instead of throwing. Logs carry exception class names only, since connection errors include the URL with the API key.
• PasswordPolicy.validate() mirrors JS password_policy_impl.ts: ASCII character classes, symbols count only when listed in allowedNonAlphanumericCharacters, min defaults to 6, max applies only when set.
• Tests use a fake HTTP client and a loopback server, never the network.

---

Maintainer note: Part of internal CPRN-449

[gemini-code-assist]

Code Review

This pull request introduces a password policy configuration and validation mechanism for Firebase UI Auth, including classes to parse, validate, fetch, and cache the policy from the Identity Toolkit API. The implementation is well-tested across various scenarios. However, a critical concurrency issue was identified in PasswordPolicyRepository.lockFor where the non-atomic ConcurrentHashMap.getOrPut extension function is used, which could lead to duplicate concurrent network requests under high load. Replacing this with putIfAbsent is recommended to ensure thread safety.

[gemini-code-assist]

The use of ConcurrentHashMap.getOrPut is not thread-safe because getOrPut is an inline extension function on MutableMap that does not execute atomically. Under high concurrency, multiple threads calling lockFor for the same key can simultaneously observe a null value, instantiate separate Mutex instances, and overwrite each other in the map. This defeats the purpose of the lock and can lead to duplicate concurrent network requests.\n\nTo ensure atomicity across all Android API levels without relying on API 24+ computeIfAbsent (which requires library desugaring), you can use putIfAbsent to safely and atomically initialize the Mutex.

    private fun lockFor(key: Key): Mutex {
        val existing = locks[key]
        if (existing != null) return existing
        val newMutex = Mutex()
        val old = locks.putIfAbsent(key, newMutex)
        return old ?: newMutex
    }