gcInterval default of 10s causes unnecessary load at scale — consider higher default or documentation guidance

[fastly-ffej]

We operate a SPIRE deployment managing 10,000+ edge node entries via the JSON provider and noticed that the default gcInterval of 10 seconds causes a ListEntries RPC to the SPIRE server every 10 seconds even under completely stable conditions.

At this scale the idle GC loop creates meaningful unnecessary load. We are raising it to 1 hour, which is appropriate for us because:

• All entry creation and deletion is event-driven — CRD changes and fsnotify file events trigger immediate reconciliation, so gcInterval fires only when the controller is idle with no incoming events
• PR perf: optimize reconcile duration by disable deepcopy and add LRU cache #632 optimized the GC loop cost via LRU caching, but at large enough entry counts even a cheap RPC every 10s accumulates non-trivial overhead over time

Questions for maintainers:

1. Was 10s a deliberate choice, or an arbitrary initial default? We found no discussion of it in issues or PRs.
2. Would it be reasonable to raise the default (e.g. to 1h or 30m) for a future release, or add documentation guidance for large-scale deployments?
3. Is there any scenario where a low value like 10s matters for correctness beyond what event-driven reconciliation already handles?