[ETCM-531] Cache-based blacklist implementation [!pr]

[1015bit]

Description

The current implementation doesn't allow the blacklist to be shared between multiple actors (e.g. fast-sync and upcoming branch resolver). This PR adds a new and thread-safe implementation that can be access and modified by multiple actors.

Proposed Solution

Requirements of the blacklist include thread-safety, time-based expiration and size-based eviction of elements. Using a cache like Caffeine provides all the required features and introduces less complexity than implementing an actor-based DIY solution.

In the future, regular sync will also be moved to this new approach. The current/old blacklist and peerlist implementations will then be removed.

Important Changes Introduced

• Added a cache-based blacklist implementation that is now used for fast-sync
• Added an updated support for peerlist that uses the new blacklist implementation

Testing

• one new test for cache-based blacklist
• updated test for fast-sync

[1015bit]

Mostly copied from PeerListSupport with a little bit of cleanup. PeerListSupport will go away eventually and then this will be renamed to PeerListSupport.

[pullrequest]

✅ This pull request was sent to the PullRequest network.

---

@pbvie you can click here to see the review status or cancel the code review job - or - cancel by adding [!pr] to the title of the pull request.

[pullrequest]

Looks like this should properly implement the cache-based blacklist 👍 It looks like other reviewers already did a thorough job, so I didn't have much to add other than some minor non-blocking comments.

Please let me know if you want me to look at something in more detail!

Brian

---

Was this helpful? Yes | No

Reviewers will be notified any time you reply to their comments or commit new changes.
You can also request a full follow-up review from your PullRequest dashboard.

[pullrequest]

This pull request would normally be cancelled because the title contains "[!pr]"; however since the review was requested manually from the PullRequest dashboard, it was sent to our network to be reviewed. If you wish to cancel PullRequest review, you can do so manually from the PullRequest dashboard.

[1015bit]

This pull request would normally be cancelled because the title contains "[!pr]"; however since the review was requested manually from the PullRequest dashboard, it was sent to our network to be reviewed. If you wish to cancel PullRequest review, you can do so manually from the PullRequest dashboard.

Which asks permissions to "act on your behalf" and view all your email addresses when all I wanna do is unsubscribe... 👎

[pullrequest]

This code looks quite good overall. I left a couple of inline comments on updatePeers pointing out some additional considerations there. It also seems like it may be worthwhile to check the thread safety of this implementation. Aside from those, this code looks good to go.

Eric E

---

Was this helpful? Yes | No

Reviewers will be notified any time you reply to their comments or commit new changes.
You can also request a full follow-up review from your PullRequest dashboard.