[ISSUE] Refactor MemoryMcpCacheIndex to remove read-path LRU contention and improve cache consistency #14932

Background

McpCacheIndex is the cache abstraction used by MCP-related query paths, and its default implementation is MemoryMcpCacheIndex.

The current implementation maintains:

• in-memory name -> id and id -> data indexes
• a hand-rolled LRU doubly linked list
• capacity eviction
• periodic cleanup

However, the current design has a concurrency and maintainability problem:

• cache read paths (getMcpId, getMcpServerById) also update LRU order
• this makes reads effectively carry write semantics
• the implementation currently relies on ReadWriteLock plus synchronized linked-list operations to keep the list consistent
• under high-QPS read scenarios, this can become a hotspot and reduces the benefit of concurrent reads

Problem

There are three main concerns in the current implementation:

1. Concurrency model mismatch

   • read operations mutate the LRU list
   • multiple concurrent readers can still contend on internal mutation paths

2. Performance hotspot

   • synchronized protection around LRU node movement serializes hot reads
   • this can degrade throughput in MCP lookup scenarios

3. Complexity and consistency risk

   • the cache maintains two maps plus a custom linked list
   • expiration, eviction, and invalidation need to keep multiple structures consistent
   • removing by ID may require extra cleanup work to keep name -> id mappings correct

Proposal

Replace the hand-written LRU implementation in MemoryMcpCacheIndex with a Caffeine-backed local cache while keeping the McpCacheIndex interface unchanged.

Recommended direction:

• keep McpCacheIndex API unchanged
• keep MemoryMcpCacheIndex as the default implementation class to minimize integration churn
• use Caffeine for:
  • maximum size based eviction
  • expire-after-write semantics
  • access tracking / eviction policy management
• keep name -> id mapping as a lightweight secondary index
• use cache removal callbacks to clean related name mappings and preserve index consistency
• keep existing configuration properties as much as possible to avoid operational impact

Expected Benefits

• remove read-path manual LRU mutation and lock contention
• reduce custom concurrent data structure complexity
• improve maintainability and correctness
• keep changes localized to the ai module and minimize PR merge conflict risk
• preserve current business-facing interface and wiring

Compatibility Notes

To reduce review risk, this refactor should:

• avoid changing McpCacheIndex consumers
• preserve current configuration names
• prefer expireAfterWrite to stay close to current semantics
• add focused tests for:
  • eviction behavior
  • expiration cleanup
  • name/id index consistency
  • concurrent read/write access
  • shutdown behavior

Scope

Impacted areas are expected to be mainly inside the ai module:

• MemoryMcpCacheIndex
• McpServerIndexConfiguration
• ai/pom.xml
• related cache tests