feat: Cache gpu_alloc_map in Redis, and Add RescanGPUAllocMaps mutation

[jopemachine]

Why?

Since gpu_alloc_map exists on the agent, querying this field requires an RPC call.

In a production environment with multiple agents, repeatedly querying this field is inefficient and can significantly slow down response time.

How it works

This PR addresses the inefficiency by caching gpu_alloc_map in the REDIS_STAT_DB, and introduces RescanGPUAllocMaps mutation for updating this cache.

RescanGPUAllocMaps takes agent_id as an argument to scan the gpu_alloc_map of a specific agent. Or it can accept None as an argument to iterate through all agents in the "Alive" state and scan their allocation maps.
The scan results are cached in Redis in JSON format.

Example

For example, the key for the alloc_map of an agent with the ID i-ubuntu will be gpu_alloc_map.i-ubuntu, and its value is like the below form.

// {"device_id": "value"}
{"c59395cd-ac91-4cd3-a1b0-3d2568aa2d04": "8.00"}

---

Checklist: (if applicable)

• Milestone metadata specifying the target backport version
• Test case(s) to:
  • Demonstrate the difference of before/after
  • Demonstrate the flow of abstract/conceptual models with a concrete implementation

---

📚 Documentation preview 📚: https://sorna--3293.org.readthedocs.build/en/3293/

---

📚 Documentation preview 📚: https://sorna-ko--3293.org.readthedocs.build/ko/3293/

[jopemachine]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat: Cache gpu_alloc_map in Redis, and Add RescanGPUAllocMaps mutation #3293 👈 (View in Graphite)
• feat: Scanning GPU allocation map #2273
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.