Fix bug causing no response flush sometimes when IO threads are busy

[murphyjacob4]

When we attempt to process commands from IO thread reads a second time, we never call handleClientsWithPendingWrites after that point. This sometimes causes the following sequence resulting in no response flush:

1. After handleClientsWithPendingWrites, we attempt to call processIOThreadsReadDone again
2. Within processIOThreadsReadDone, we write some response back to the client
3. The response is unable to be sent to the IO thread (e.g. IO thread job queue full)
4. !!! We never call handleClientsWithPendingWrites to process that write on the main thread or install the write handler !!!

Adding a second call to handleClientsWithPendingWrites should fix it. This call should be cheap since it fast returns when there are no pending writes.

Fixes #3198

[murphyjacob4]

On another note, I'm not sure if this "second read" gives much better performance. But this path is very unlikely to be triggered in our tests and feels like a time bomb given the low path coverage. Maybe we should consider removing it. But let's fix it first

[murphyjacob4]

I think we need to backport down to 8.0. Although I had trouble reproducing since without the pipeline optimization it doesn't seem as likely to trigger.

https://github.com/valkey-io/valkey/blob/8.0/src/server.c#L1719-L1722

[enjoy-binbin]

It looks like a clever trick.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 0.00%. Comparing base (fd57c21) to head (09894a5).
⚠️ Report is 1 commits behind head on unstable.

Additional details and impacted files

@@       Coverage Diff        @@
##   unstable   #3205   +/-   ##
================================
================================

🚀 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.