[Controller] Add gRPC support for listStores API

[pthirun]

Problem Statement

As part of the controller gRPC migration, the listStores API needs to be available via gRPC while maintaining the existing HTTP endpoint during the migration period. This follows the same pattern established by other controller API migrations, where business logic is abstracted so both HTTP and gRPC can share the same implementation.

Solution

Added gRPC support for the listStores API following the established migration pattern:

1. Proto definitions (StoreGrpcService.proto): Added listStores RPC method with ListStoresGrpcRequest and ListStoresGrpcResponse messages, including support for filtering (includeSystemStores, storeConfigNameFilter, storeConfigValueFilter)
2. Request handler (StoreRequestHandler.java): Added listStores() method that validates parameters and calls admin.getAllStores() with filtering support, returning a gRPC response
3. gRPC service implementation (StoreGrpcServiceImpl.java): Added listStores() override (no ACL check, consistent with HTTP endpoint behavior)
4. HTTP route update (StoresRoutes.java): Updated getAllStores() to convert HTTP requests to gRPC format and delegate to the shared handler
5. Route registration (AdminSparkServer.java): Updated to pass the request handler to the route

The implementation reuses the existing business logic in Admin.getAllStores(), ensuring consistency between HTTP and gRPC endpoints.

Code changes

• Added new code behind a config. If so list the config names and their default values in the PR description.
• Introduced new log lines.
  • Confirmed if logs need to be rate limited to avoid excessive logging. (Debug level logging only, consistent with other gRPC endpoints)

Concurrency-Specific Checks

Both reviewer and PR author to verify

• Code has no race conditions or thread safety issues. (Stateless request handling, delegates to existing thread-safe Admin methods)
• Proper synchronization mechanisms (e.g., synchronized, RWLock) are used where needed. (N/A - no shared mutable state)
• No blocking calls inside critical sections that could lead to deadlocks or performance degradation. (N/A - no critical sections)
• Verified thread-safe collections are used (e.g., ConcurrentHashMap, CopyOnWriteArrayList). (N/A - no collections introduced)
• Validated proper exception handling in multi-threaded code to avoid silent thread termination. (Uses handleRequest() utility for consistent error handling)

How was this PR tested?

• New unit tests added.
  • testListStoresReturnsSuccessfulResponse - Verifies successful response with stores list
  • testListStoresReturnsErrorResponse - Verifies error handling
  • testListStoresWithBadRequest - Verifies validation of invalid requests
  • testListStoresWithFilters - Verifies filtering functionality
  • testGetAllStores - Verifies HTTP route success case
  • testGetAllStoresReturnsEmptyList - Verifies empty list handling
  • testGetAllStoresReturnsError - Verifies HTTP error handling
  • testGetAllStoresWithFilters - Verifies HTTP filter handling
• New integration tests added.
  • testListStoresGrpcEndpoint - End-to-end test with real cluster
• Modified or extended existing tests.
• Code coverage verified.
  • Generated Jacoco coverage report: ./gradlew :services:venice-controller:test :services:venice-controller:jacocoTestReport
  • Verified 100% instruction and branch coverage for all new methods
• Verified backward compatibility (if applicable). (HTTP endpoint unchanged, gRPC is additive)

Does this PR introduce any user-facing or breaking changes?

• No. You can skip the rest of this section.
• Yes. Clearly explain the behavior change and its impact.

[sushantmane]

LGTM. Thanks!