[ALSP] Implements disallowlisting logic

[yhassanzadeh13]

This PR concludes the development of the Application Layer Spam Prevention (ALSP) Reputation Management System (RMS) within the Flow blockchain by implementing its sixth and final part. The key objective of this PR is to equip the ALSP manager with the capability to allow-list and disallow-list nodes. A node is disallow-listed if its accumulated penalty drops below a specified threshold, resulting in termination of the existing connection and prevention of any future connections. Once the penalties for a disallow-listed node have fully decayed, it is reinstated to the allow-list, allowing the establishment of a connection with it.

Furthermore, this PR introduces several enhancements and refinements:

• Centralization of Decision-making: The logic for disallow-listing decisions has been integrated into the libp2p node, centralizing this aspect.
• Streamlining Notification Handling: By relocating and simplifying the disallow-listing notification logic to the middleware, the need for a separate pubsub architecture by the notification distributor has been eliminated. This is because the middleware is the sole entity that should consume these notifications to prevent conflicts.
• Terminology Standardization: All terms related to blocklisting have been updated to the more consistent "disallow-listing".
• Race Condition Mitigation in Tests: A race condition that was present among connection gaters in the test utilities has been addressed. This was achieved by ensuring that each node is provided with a unique and isolated instance of a connection gater during testing.
• Middleware Initialization Refinement: Middleware initialization has been streamlined through the incorporation of a configuration structure.
• Logic Migration for Consistency and Scalability: Certain logics have been moved from the middleware to the libp2p node. This realignment is in accordance with the long-term objective of segregating middleware from the network and libp2p components, contributing to a more scalable and maintainable codebase.

This PR not only concludes the development of the ALSP RMS component but also enhances the overall system's robustness, efficiency, and maintainability.

Follow-up issues:
[Application Layer Spam Prevention] Implement Batch Mode for Sending Disallow-Listing Notifications in MisbehaviorReportManage

[peterargue]

This is a 600x increase in the number of peer updates. Is that safe to do? I was under the impression this was an expensive operation

flow-go/network/p2p/connection/peerManager.go

Lines 87 to 88 in 0ee0a2a

	// add a random delay to initial launch to avoid synchronizing this
	// potentially expensive operation across the network

[yhassanzadeh13]

Summarizing our discussion:

Shortening the peer update intervals is safe due to two factors. Firstly, with this PR's changes, connections are established with nodes only if they don’t exist already, making this update inconsequential if there are no changes in the allow-listed or staked peers. Secondly, it's vital for the network layer's safety measures that all heartbeats are synchronized. This ensures, for example, that if the ALSP disallow-lists a node within a heartbeat, the disallow-listing is guaranteed to be completed by the next heartbeat.

[peterargue]

Using a core component like Middleware as the distributor for these notifications is going to cause weird dependency chains, like you flagged in NodeDisallowListingWrapper.

What do you think about keeping the distributor as a stand along component instead? That way it can be built and passed into components separately.

[yhassanzadeh13]

In this PR, we observed that distributing the disallow-listing notification is unnecessary since it has only one consumer, the middleware. Therefore, this PR directly connects the consumer to the notification producer. Given that there's just one consumer, having a distributor broker seems excessive. Additionally, as we’re phasing out the middleware in favor of integrating it into the LibP2PNode and network components. Eventually, only the network layer will consume these notifications. This aligns well architecturally with the network layer handling notifications regarding node disallow-listing at the network level.

[gomisha]

LGTM, just a few minor typos.