Add support for asynchronous release to slaveKeysWithExpire on writable replica

[Scut-Corgis]

Problem

When executing FLUSHALL ASYNC on a writable replica that has
a large number of expired keys directly written to it, the main thread
gets blocked for an extended period while synchronously releasing the
slaveKeysWithExpire dictionary.

Root Cause

FLUSHALL ASYNC is designed for asynchronous lazy freeing of core data
structures, but the release of slaveKeysWithExpire (a dictionary tracking
expired keys on replicas) still happens synchronously in the main thread.
This synchronous operation becomes a bottleneck when dealing with massive
key volumes, as it cannot be offloaded to the lazyfree background thread.

This PR addresses the issue by moving the release of slaveKeysWithExpire
to the lazyfree background thread, aligning it with the asynchronous design
of FLUSHALL ASYNC and eliminating main thread blocking.

User scenarios

In some operations, people often need to do primary-replica switches.
One goal is to avoid noticeable impact on the business—like key loss
or reduced availability (e.g., write failures).

Here is the process: First, temporarily switch traffic to writable replicas.
Then we wait for the primary pending replication data to be fully synced
(so primry and replicas are in sync), before finishing the switch. We don't
usually need to do the flush in this case, but it's an optimization that can
be done.

other infomation

This PR includes the same changes that were previously submitted to valkey and have been merged.
valkey-io/valkey#2849

[jit-ci]

Hi, I’m Jit, a friendly security platform designed to help developers build secure applications from day zero with an MVS (Minimal viable security) mindset.

In case there are security findings, they will be communicated to you as a comment inside the PR.

Hope you’ll enjoy using Jit.

Questions? Comments? Want to learn more? Get in touch with us.

[CLAassistant]

All committers have signed the CLA.