Only mark the client reprocessing flag when unblocked on keys (#2…

[ranshid]

NOTE - this is a backport of #2109

When we refactored the blocking framework we introduced the client
reprocessing infrastructure. In cases the client was blocked on keys, it
will attempt to reprocess the command. One challenge was to keep track
of the command timeout, since we are reprocessing and do not want to
re-register the client with a fresh timeout each time. The solution was
to consider the client reprocessing flag when the client is
blockedOnKeys:

if (!c->flag.reprocessing_command) {
        /* If the client is re-processing the command, we do not set the timeout
         * because we need to retain the client's original timeout. */ c->bstate->timeout = timeout; } 

However, this introduced a new issue. There are cases where the client
will consecutive blocking of different types for example:

CLIENT PAUSE 10000 ALL
BZPOPMAX zset 1

would have the client blocked on the zset endlessly if nothing will be
written to it.

Credits to @uriyage for locating this with his fuzzer testing

The suggested solution is to only flag the client when it is
specifically unblocked on keys.

[enjoy-binbin]

so we are doing this backport thing one PR by on PR?

[ranshid]

so we are doing this backport thing one PR by on PR?

The cherry-pick was just impossible

[ranshid]

so we are doing this backport thing one PR by on PR?

The cherry-pick was just impossible

And I think since the code is somewhat different it require a separate PR. If you prefer I can eliminate this PR and include in the release PR but changes there are going to be strange IMO

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 0.00%. Comparing base (a9b02f1) to head (db6c29f).
Report is 1 commits behind head on 7.2.

Additional details and impacted files

@@     Coverage Diff     @@
##   7.2   #2231   +/-   ##
===========================
===========================

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.