[FUN-1332] Allowlist optimisation

[agparadiso]

Description

this pr introduces an optimization for allowlist by updating it in batches giving priority to latest allowed addresses and adding an extra step on the batching process in which we check for the length of the allowlist and if it changed (new addresses were added) we fetch these before continuing the loop

What changed

We are adding an extra step that will fetch the latest addresses added IF the length of the allowlist was increased.

We were already fetching the allowlist from the contract in batches, but we were updating the node representation only when the full list was fetched. This represented a delay for users when a new address was added, which would grow proportional to the increase of the allowlist length.

In order to mitigate this, we are updating the nodes representation with every batch we fetch.

Because the nodes representation uses a atomic.Pointer[map[common.Address]struct{}] we only have a Store method to replace completely the current list.

So we what we are doing is:

• get the current allowlist node's state by using the a.allowlist.Load()
• fetch the allowlist in batches from the contract (starting by latest addresses added)
• append the batch to a copy of the node's current state and replace the list
• clean the blocked list at the db layer

by doing this the user should be able to see the new added addresses faster than waiting until the full list is fetched.

miro diagram here

How is this tested

This is tested with white box unit tests that mock the onchain part and allows to validate the correct fetching order

[github-actions]

I see you updated files related to core. Please run pnpm changeset in the root directory to add a changeset as well as in the text include at least one of the following tags:

• #added For any new functionality added.
• #breaking_change For any functionality that requires manual action for the node to boot.
• #bugfix For bug fixes.
• #changed For any change to the existing functionality.
• #db_update For any feature that introduces updates to database schema.
• #deprecation_notice For any upcoming deprecation functionality.
• #internal For changesets that need to be excluded from the final changelog.
• #nops For any feature that is NOP facing and needs to be in the official Release Notes for the release.
• #removed For any functionality/config that is removed.
• #updated For any functionality that is updated.
• #wip For any change that is not ready yet and external communication about it should be held off till it is feature complete.

[KuphJr]

The general approach seems valid to me. Justs add some tests and I think we can give this another review.

[cl-sonarqube-production]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
81.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube