[Fix] Sweep: delete after iteration.

[ruseinov]

Summary of changes

Changes introduced in this pull request:

• GC: avoids ParityDB concurrency issues be scheduling items for deletion after iterating all the columns.

Reference issue to close (if applicable)

Closes

Other information and links

Change checklist

• [x] I have performed a self-review of my own code,
• [ ] I have made corresponding changes to the documentation,
• [ ] I have added tests that prove my fix is effective or that my feature works (if possible),
• [x] I have made sure the CHANGELOG is up-to-date. All user-facing changes should be reflected in this document.

[ruseinov]

1. If it fixes the GC, it's worth adding a changelog entry.
2. Could you please describe the manual tests you performed to assess that GC is working?
3. Is it feasible to have an automatic test to reproduce the original issue and catch future regressions?

1. Yes, I wasn't sure about it.
2. Two types of tests: a. Running the GC every 90 seconds and making sure it does not remove reachable records b. Running the GC on a weak node for several days on a normal schedule, same result
3. Unfortunately too complicated, the regressions happened due to truncated_hash, too many collisions. This does not even show immediately on a mainnet snap running the GC pretty often, so no way to reliably reproduce this, unless we tie the implementation to now-obsolete truncated_hash.