DESIGN: improve RENAME complexity for huge containers

[romange]

Background

Consider a use-case of of huge hashes, sets etc that take up gigabytes of memory. Currently RENAME physically copies the between threads which creates a) memory spikes b) CPU spikes and stalls.

Ideally we would like to solve both. This is a root task for designing a solution. The end goal: this issue should be evolved and broken down into a sub-tasks that will lead to solution

[adiholden]

Suggested solution:
When renaming a key with a large value (above a defined threshold) across different shards, we store an entry in a thread-local rename hash map, which is replicated across all threads. This map tracks large-key rename operations by mapping the new key name to the an internal Dragonfly key name from the source shard.

During command execution, in the coordinator fiber while initializing transaction keys, we first check if the rename map is non-empty. If it is, we verify whether the key involved in the transaction exists in the map. If found, the command is rewritten to use the internal key name to ensure correct routing.

Special considerations with this approach:
Snapshotting:
When creating a snapshot, we must serialize the renamed key (the logical name) rather than the internal key stored in the dash table.

Journal replication:
When sending journal changes to replicas, we should serialize the renamed (logical) key, without substituting it with the internal key name.