fix: re-read sessionCache inside synchronized block in getOrCreateSessionCache (#242)

The double-checked locking pattern in getOrCreateSessionCache() had a bug:
  the local variable 'cache' was not updated after another thread won the
  initialization race inside the synchronized block. The losing thread would
  return null, causing a NullPointerException at cache.cachedSession() in
  tableSession() (line 94).

  This surfaces when multiple threads call tableSession() simultaneously on
  the first Iceberg commit — for example, when an Iceberg Kafka Connect sink
  flushes several Parquet files in parallel. It became observable in
  iceberg-kafka-connect 1.11.0 after apache/iceberg#13215 changed
  S3V4RestSignerClient to call authManager().tableSession() on every S3
  request instead of caching the session per instance.

  Fix: re-read sessionCache from the volatile field inside the synchronized
  block so the losing thread picks up the value set by the winner.

Author: nijordia

oauth2/core/src/main/java/com/dremio/iceberg/authmgr/oauth2/OAuth2Manager.java

@@ -136,7 +136,8 @@ private AuthSessionCache getOrCreateSessionCache(Map<String, String> properties)
     AuthSessionCache cache = sessionCache;
     if (cache == null) {
       synchronized (this) {
-        if (sessionCache == null) {
+        cache = sessionCache;
+        if (cache == null) {
           OAuth2Config config = OAuth2Config.from(properties);
           cache = new AuthSessionCache(name, config.getSystemConfig().getSessionCacheTimeout());
           sessionCache = cache;