Fix incorrect kvstore size and BIT accounting after completed migration

[murphyjacob4]

When working on #2635 I errorneously duplicated the setSlotImportingStateInAllDbs call for successful imports. This resulted in us doubling the key count in the kvstore. This results in DBSIZE reporting an incorrect sum, and also causes BIT corruption that can eventually result in a crash.

The solution is:

1. Only call setSlotImportingStateInAllDbs once (in our finishSlotMigrationJob function)
2. Make setSlotImportingStateInAllDbs idempotent by checking if the delete from the kvstore importing hashtable is a no-op

This also fixes a bug where the number of importing keys is not lowered after the migration, but this is less critical since it is only used when resizing the dictionary on RDB load. However, it could result in un-loadable RDBs if the importing key count gets large enough.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.63%. Comparing base (b4c93cc) to head (956f376).
⚠️ Report is 1 commits behind head on unstable.

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #2749      +/-   ##
============================================
+ Coverage     72.59%   72.63%   +0.04%     
============================================
  Files           128      128              
  Lines         71301    71300       -1     
============================================
+ Hits          51759    51791      +32     
+ Misses        19542    19509      -33     

Files with missing lines	Coverage Δ
src/cluster_migrateslots.c	92.22% <ø> (+0.14%)	⬆️
src/kvstore.c	96.01% <100.00%> (ø)

... and 17 files with indirect coverage changes

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

[zuiderkwast]

Looked at the code change but I didn't read the test cases carefully.

We should hurry and include this in 9.0.0, otherwise we're releasing with this known bug. Or should we already plan for 9.0.1?

[murphyjacob4]

I agree - let's get it in to 9.0.0