feat: Regional access boundaries

[vverman]

Contains changes for the feature Regional Access Boundary (Previously Called Trust Boundaries).

The following are salient changes:

• Calls to refresh RAB are now all async and in a separate thread, we use the Executor pattern here.
• Logic for refreshing RAB now exists in its own class for cleaner maintenance.
• Self-signed jwts are within scope.
• Changes to how we trigger RAB refresh and deal with refresh errors.
• The env. variable gate for RAB has been removed.

[gemini-code-assist]

Code Review

This pull request introduces support for Regional Access Boundaries (RAB) across various credential types, including Compute Engine, External Account, and Service Account credentials. It adds a RegionalAccessBoundaryManager to handle the asynchronous fetching, caching, and cooldown logic for RAB data, which is then included as an x-allowed-locations header in outgoing requests. Feedback includes removing unnecessary .rej files from the repository, replacing an unbounded thread pool with a bounded one for safety, and simplifying the logic for adding quota project IDs to request metadata.

[gemini-code-assist]

The use of an unbounded thread pool (Executors.newCachedThreadPool()) is discouraged as it can lead to excessive thread creation under high load. Per the general rules, a bounded thread pool should be used instead.

  private static final ExecutorService REFRESH_EXECUTOR =
      new java.util.concurrent.ThreadPoolExecutor(
          0,
          100,
          60L,
          java.util.concurrent.TimeUnit.SECONDS,
          new java.util.concurrent.SynchronousQueue<Runnable>(),
          new ThreadFactory() {
            @Override
            public Thread newThread(Runnable r) {
              Thread t = new Thread(r, "RAB-refresh-thread");
              t.setDaemon(true);
              return t;
            }
          });

References

1. For safety, use a bounded thread pool (e.g., ThreadPoolExecutor with a defined maximum size) instead of an unbounded one (e.g., Executors.newCachedThreadPool()), even if the current logic seems to limit concurrent tasks.

[vverman]

Done! We now use these bounds

 private static final int CORE_POOL_SIZE = 0;
  private static final int MAX_POOL_SIZE = 100;
  private static final long KEEP_ALIVE_TIME_SECONDS = 60L;
  private static final int QUEUE_CAPACITY = 100;