tree 36446df70d0189ae4598652e2c0cae06a96f37e5
parent 2f6cafa26e103beb30b8fc30130405bf1b8c2853
author James Hawkins <jhawkins@google.com> 1788977523 +0000
committer James Hawkins <jhawkins@google.com> 1788979700 +0000

Add in-memory CodeOwnerConfigCache across requests

TransientCodeOwnerConfigCache was originally transient to prevent
returning stale CodeOwnerConfig entries when getFromCurrentRevision
passed revision = null.

This change introduces CodeOwnerConfigCache, a thread-safe in-memory
cache keyed strictly by (CodeOwnerConfig.Key, ObjectId revision)
configured via CacheModule in BackendModule, exposing it to Gerrit's
cache metrics (Prometheus) and administrative commands (show-caches,
flush-caches).

Because entries are keyed by immutable Git commit ObjectIds, entries
never become stale, and eviction is governed purely by the configured
maximum cache size (LRU).

TransientCodeOwnerConfigCache maintains the L1 (request-local) -> L2
(process-wide) cache hierarchy:
- L1 hits return in O(1) time without Git ref resolution.
- On an L1 miss, branch revision is resolved once and L2 is checked.
- On an L2 hit, L1 is populated for fast subsequent lookups, respecting
  the per-request cache size limit.
- On an L2 miss, the config is loaded and cached in both L1 and L2.
- Non-existent branches are cached in L1 to prevent repeated disk I/O.

Cost/Benefit:
- Benefit: Eliminates repeated Git tree walks, distributed blob reads,
  and OWNERS parsing across the push and submit requirement validation
  lifecycle, saving an estimated ~500 ms to 1.5+ seconds per patch set
  upload on large repositories like chromium/src.
- Cost: Up to ~10-50 MB JVM heap overhead for 10k cached configs.

Change-Id: I1983e074bd896aa2fc1594bb68e0801aa653853b