Always untrack initialized safe iterator

[ranshid]

in #2807 we added safe-iterator invalidation when a hashtable is deleted.
When we create a safeIterator we initialize it to it->table=0 and it-index=-1.
HOWEVER say someone creates a safe iterator never progress it and later on just delete the iterator using hashtableReleaseIterator.
the iterator will NOT be untracked since, hashtableCleanupIterator will skip the untrack:

    if (!(iter->index == -1 && iter->table == 0)) {
        if (isSafe(iter)) {
            hashtableResumeRehashing(iter->hashtable);
            untrackSafeIterator(iter);
        } else {
            assert(iter->fingerprint == hashtableFingerprint(iter->hashtable));
        }
    }

and then when the hashtable is freed the iterator will be referenced leading to a use-after-free.

For example:

    it = hashtableCreateIterator(ht, HASHTABLE_ITER_SAFE);
    hashtableReleaseIterator(it);
    hashtableRelease(ht);

This PR fix it by ALWAYS untrack safe iterators which have a valid hashtable when they are being cleaned up.

[rainsupreme]

LGTM!

[codecov]

Codecov Report

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

Additional details and impacted files

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

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

@ranshid does this need to be backported as well to Valkey 9.0?

[ranshid]

@ranshid does this need to be backported as well to Valkey 9.0?

@sarthakaggarwal97 no. AFAIK we never backported #2807 which is the source of this specific degradation