[CON-213] - Paginate delist adding and small refactor

[vicky-g]

Description

Purpose: To prevent OOM errors on delist init.
New behavior: This PR is to paginate adding content to the delist init + remove an unused part of the adding (bug discovered on paginating the add).

See design doc for more info

Tests

Automated:
There is no net new functionality, just batching, removing a flow that is not used, and adding retries.

Manual:

• Deployed this branch hash to stage content node 5 to observe if the ipfs route still works as expected and it does.
• The time spent in init'ing the class is ~77001ms (1min 17s), with batch size of 200

Monitoring - How will this change be monitored? Are there sufficient logs / alerts?

The CN should not come up if the initialization fails to add content. And the content node will print out the init err if the init does fail.

We have some retries here with the log addAggregateCIDsToRedis to tell us if the app fails to come up.

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	Secret	Commit	Filename
3509188	Generic High Entropy Secret	054316a	.circleci/config.yml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

<sup>🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

Our GitHub checks need improvements? Share your feedbacks!</sup>

[dmanjunath]

pagination and cleanup of REDIS_MAP_BLACKLIST_SEGMENTCID_TO_TRACKID_KEY look great. biggest question i have is does the nginx cache have something to do with this PR or is that just an unrelated change? also we should put back any tests that have been skipped

[dmanjunath]

@vicky-g this is with prod db and disk state?

• The time spent in init'ing the class is ~77001ms (1min 17s), with batch size of 200

[vicky-g]

@vicky-g this is with prod db and disk state?

• The time spent in init'ing the class is ~77001ms (1min 17s), with batch size of 200

no, this is just with the db state. the disk was not copied over, but it shouldnt matter since the delisting initialization does not touch things on disk

[dmanjunath]

looks good! left one more question but not blocking, if you think we need async retry go ahead and merge