Fixes memory leak when the job crashes before it's freed

[sarthakaggarwal97]

If there is a crash between the time the job is popped and freed, we technically leak memory. This change allows us to peek, and pop just before we are about to free the job.

Fixes valgrind errors: https://github.com/valkey-io/valkey/actions/runs/21969557125/job/63467641572#step:6:8648

[codecov]

Codecov Report

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

Additional details and impacted files

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

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

[sarthakaggarwal97]

@madolson looks like valgrind is green with this PR: https://github.com/sarthakaggarwal97/valkey/actions/runs/21770227707

Do you have any feedbacks on this change on a high level? I know we discussed that this is a bit inefficient.

[sarthakaggarwal97]

@madolson valgrind run is green: https://github.com/sarthakaggarwal97/valkey/actions/runs/21887850029/job/63288991006

[Nikhil-Manglore]

LGTM

[JimB123]

@madolson Good to see that this change resolves the test issue.

However, I'm not keen on the API change. It's common/typical for a mutex queue to support multiple readers. By adding a peek API, it becomes confusing for this common case. A second reader can pop the item that was peeked - or 2 readers can peek the same thing.

I'll look into alternatives.

[madolson]

However, I'm not keen on the API change. It's common/typical for a mutex queue to support multiple readers. By adding a peek API, it becomes confusing for this common case. A second reader can pop the item that was peeked - or 2 readers can peek the same thing.

Another thing we considered was to have a global/static pointer which keeps track of the per-thread objects. So even when the thread is killed, there is still a global reference so valgrind is happy.

I am indifferent to the new API, but we needed a fix for the valgrind issue.