feat: add pending connection limits + bump libp2p to 0.54.1

[MitchTurner]

Linked Issues/PRs

Replaces: #2150

• Closes Add connection_limits behavior to FuelBehavior #1560
• related to Add config options for max pending connections, for both outgoing and incoming #904 but doesn't close completely because of (wrt to max_pending_outgoing_connections):

Even though I've added this parameter, I'm not fully sold that it should be present. The rationale is we only dial a peer if:
a) We are below the desired amount of peers in a gossipsub mesh (which would imply we would be below any potential max_pending_outgoing_connections anyway) and we determined that the peer in question would have a reasonable peer score. So essentially our gossipsub config should handle this scenario.
AND
b) We are relatively certain that peer is reachable i.e. the multiaddr for that peer can be successfully dialled - if that is so, we want to prioritize dialling it.
But I may be missing something about the current p2p setup.

Description

This is apart of the broader initiative outlined in #1968 to improve the DoS resilience

This PR doesn't make the pending connection limits configurable for a reason, it is an easy way for the operator to footgun and mess up the node configuration. We've used some defaults for now, but there should be some analysis done on optimal connection count for latency to propagate messages.

Checklist

• Breaking changes are clearly marked as such in the PR description and changelog

Before requesting review

• I have reviewed the code myself

[fuel-cla-bot]

Thanks for the contribution! Before we can merge this, we need @maschad to sign the Fuel Labs Contributor License Agreement.

[AurelienFT]

@MitchTurner Can we update to libp2p 0.55 directyl it would fix : #2488

[MitchTurner]

@MitchTurner Can we update to libp2p 0.55 directyl it would fix : #2488

@AurelienFT I'd be happy to, but it looks like it requires Rust v1.83. So maybe we wait until we update the Rust version?

[rymnc]

will not approve, will allow others to review

[netrome]

Looks mostly good to me. The only blocking thing I've spotted are some as conversions that could potentially panic.

[netrome]

Thanks for updating! 🙏

[acerone85]

Some suggestions on these two lines:

1. should these values be configurable, and also have a hard limit?

e.g. something like

Suggested change

	max_gossipsub_peers_connected: 100,
	max_request_response_peers_connected: 100,
	max_gossipsub_peers_connected: self.max_gossipsub_peers_connected.min(100),
	max_request_response_peers_connected: self.max_request_response_peers_connected.min(100),

2. Maybe best to declare the hardcoded constants as const variables?

3. You renamed self.max_peers_connected, but not self.max_peers_connected. (Ther argument has --max-peers-connected` as argument name hardcoded in clap_derive, so there should be no risk in renaming this

[acerone85]

nit: I find BoundedHashSet more clear

[acerone85]

I wonder if this makes the node susceptible to a DoS. It requires only 100 peers to effectively block all GossipSub messages on a target node.

[acerone85]

should there be a warn message that the node has reached the maximum number of peers?

[acerone85]

only one comment re the possibility of DoS, otherwise LGTM