The idea comes directly from ValKey:
valkey-io/valkey#3144

Deleting many fields from a hash/zset/set stored as a dict can trigger
repeated shrink/rehash work during the loop.

---------

Co-authored-by: Binbin <binloveplay1314@qq.com>
Co-authored-by: debing.sun <debing.sun@redis.com>

…tems (valkey-io#3144)

When ZREM / SREM / HDEL delete a large number of elements, we can apply the same
optimization as ZREMRANGEBY*, which is to temporarily pause the autoshrink of
the corresponding hashtable to avoid triggering resize/rehash repeatedly during
the deletion process.

This theoretically leads to some performance improvements. Furthermore, by only
triggering a resize once at the end (i.e., only when `hashtableResumeAutoShrink`
is called), we can get the most right resize, preventing further resizes during
the resize/rehash process.

Signed-off-by: Binbin <binloveplay1314@qq.com>

…tems (valkey-io#3144)

When ZREM / SREM / HDEL delete a large number of elements, we can apply the same
optimization as ZREMRANGEBY*, which is to temporarily pause the autoshrink of
the corresponding hashtable to avoid triggering resize/rehash repeatedly during
the deletion process.

This theoretically leads to some performance improvements. Furthermore, by only
triggering a resize once at the end (i.e., only when `hashtableResumeAutoShrink`
is called), we can get the most right resize, preventing further resizes during
the resize/rehash process.

Signed-off-by: Binbin <binloveplay1314@qq.com>
Signed-off-by: Harkrishn Patro <bunty.hari@gmail.com>

…3535)

Match HGETDEL with the existing batch-delete pattern used by HDEL.

HDEL already pauses hashtable auto-shrink while deleting multiple fields
so shrink evaluation is deferred until the batch completes. HGETDEL was
missing the same optimization even though it also deletes fields in a loop.

Pause auto-shrink for hashtable-encoded hashes before the HGETDEL delete
loop and resume it once afterwards. This preserves observable behavior
and reduces redundant shrink work for multi-field deletes.

Same as #3144.

Signed-off-by: DaeMyung Kang <charsyam@gmail.com>

…alkey-io#3535)

Match HGETDEL with the existing batch-delete pattern used by HDEL.

HDEL already pauses hashtable auto-shrink while deleting multiple fields
so shrink evaluation is deferred until the batch completes. HGETDEL was
missing the same optimization even though it also deletes fields in a loop.

Pause auto-shrink for hashtable-encoded hashes before the HGETDEL delete
loop and resume it once afterwards. This preserves observable behavior
and reduces redundant shrink work for multi-field deletes.

Same as valkey-io#3144.

Signed-off-by: DaeMyung Kang <charsyam@gmail.com>

…3535)

Match HGETDEL with the existing batch-delete pattern used by HDEL.

HDEL already pauses hashtable auto-shrink while deleting multiple fields
so shrink evaluation is deferred until the batch completes. HGETDEL was
missing the same optimization even though it also deletes fields in a loop.

Pause auto-shrink for hashtable-encoded hashes before the HGETDEL delete
loop and resume it once afterwards. This preserves observable behavior
and reduces redundant shrink work for multi-field deletes.

Same as #3144.

Signed-off-by: DaeMyung Kang <charsyam@gmail.com>