defrag: eliminate persistent kvstore pointer and edge case fixes

[JimB123]

This update addresses several issues in defrag:

1. In the defrag redesign (Refactor of ActiveDefrag to reduce latencies #1242), a bug was introduced where server.cronloops was no longer being incremented in the whileBlockedCron(). This resulted in some memory statistics not being updated while blocked.
2. In the test case for AOF loading, we were seeing errors due to defrag latencies. However, running the math, the latencies are justified given the extremely high CPU target of the testcase. Adjusted the expected latency check to allow longer latencies for this case where defrag is undergoing starvation while AOF loading is in progress.
3. A "stage" is passed a "target". For the main dictionary and expires, we were passing in a kvstore*. However, on flushall or swapdb, the pointer may change. It's safer and more stable to use an index for the DB (a DBID). Then if the pointer changes, we can detect the change, and simply abort the stage. (If there's still fragmentation to deal with, we'll pick it up again on the next cycle.)
4. We always start a new stage on a new defrag cycle. This gives the new stage time to run, and prevents latency issues for certain stages which don't operate incrementally. However, often several stages will require almost no work, and this will leave a chunk of our CPU allotment unused. This is mainly an issue in starvation situations (like AOF loading or LUA script) - where defrag is running infrequently, with a large duty-cycle. This change allows a new stage to be initiated if we still have a standard duty-cycle remaining. (This can happen during starvation situations where the planned duty cycle is larger than the standard cycle. Most likely this isn't a concern for real scenarios, but it was observed in testing.)
5. Minor comment correction in server.h

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.90%. Comparing base (0c8ad5c) to head (005deba).
Report is 5 commits behind head on unstable.

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #1430      +/-   ##
============================================
+ Coverage     70.76%   70.90%   +0.14%     
============================================
  Files           119      119              
  Lines         64618    64642      +24     
============================================
+ Hits          45728    45836     +108     
+ Misses        18890    18806      -84     

Files with missing lines	Coverage Δ
src/defrag.c	89.72% <100.00%> (-0.96%)	⬇️
src/server.c	87.44% <100.00%> (+0.01%)	⬆️
src/server.h	100.00% <ø> (ø)

... and 14 files with indirect coverage changes

[hpatro]

The change looks good to me. But if I understand correctly there isn't enough test coverage to discover such issues. Should we add more test with defrag to avoid things like this in future?

[hpatro]

I think we were avoiding camel cased variables in methods. But the clang format check seems to be not complaining.

[hpatro]

Talked to @JimB123, he mentioned with this change #1303, it should help us discover some of the above issues. Currently the testing with defrag is miniscule.