[Improvement] TransportCleanupRepositoryAction.cleanupRepo takes too much of cluster manager memory

Describe the bug
TransportCleanupRepositoryAction.cleanupRepo flow utilizes the cluster manager JVM very quickly. We call doGetRepositoryData method, which internally takes up 11% of overall CPU utilization as well as 6.7% of overall memory allocations. This increase in JVMMP can impact the node join flow, as there is always a need of more memory by Gateway allocator(today).

Note : there is already a bug opened in case this code flow gets stuck and make generic threadpool busy, there the idea is if we can change the threadpool. Ref : https://github.com/opensearch-project/OpenSearch/issues/1788 . Here we need to explore about the optimizations to code path, if possible.

To Reproduce
Steps to reproduce the behavior:

1. Create a big cluster with 3-4K indices and huge mapping (175MB of cluster state)
2. Take 300 snapshots.
3. Start this API for cleanup of your snapshot repository
4. Take async profiler alloc profile to see the usage.

Expected behavior
We should optimize the code path to see if there are ways to improve the overall utilization and use lesser footprint while executing this cleanup.

Plugins
N/A

Screenshots
Attaching screenshots of async profiler.

Additional context
Attaching actual profiler files here, change them to .html to view the flamegraph.

steady-state-WITH-cleanup-cpu-profile.txt
steady-state-without-cleanup-cpu-profile.txt
steady-state-without-cleanup-alloc-profile.txt
steady-state-WITH-cleanup-alloc-profile.txt

Start with TransportCleanupRepositoryAction.cleanupRepo and its doGetRepositoryData flow. Reproduce the issue with thousands of indices, a large cluster state, and many snapshots, then run the referenced async-profiler allocation and CPU profiles. Done means identifying and implementing a supported optimization that reduces cleanup's cluster-manager memory and CPU footprint.