Explicit Peering Agreement implementation

[thedevbirb]

PR Description

Implements Gossipsub v1.1 "Explicit Peering Agreement" by introducing a new CLI flag --direct-peers ("direct" is used instead of "explicit" to follow jvm-libp2p convention).
As such, documentation on https://github.com/Consensys/doc.teku should be updated as well to reflect this change (I can do it if you wish!).

Implementation

From a discovering configuration perspective, direct peers are treated as static peers, as we want to connect with them immediately on startup and persist the connection with them without being kicked out by the reputation system.
In order to do that, the list of static peers is extended with the direct peers provided in the CLI option.

Lastly, a function that determines whether a peer is direct or not is passed downstream to jvm-libp2p to enable the direct peer functionality on gossipsub.

Fixed Issue(s)

Closes #8004.

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

[CLAassistant]

All committers have signed the CLA.

[StefanBratanov]

Thanks for the PR. :) Added one comment about the DirectPeerManager initialization. Also will tag @Nashatyrev for his opinion.

[StefanBratanov]

I think is not as simple because the String will be the whole multiaddress but we only care about the multihash. I think below should suffice and also simplifies a bit with lambda:

public Builder directPeers(final List<String> directPeers) {                  
  checkNotNull(directPeers);                                                  
  final List<NodeId> directPeerNodeIds =                                      
      directPeers.stream()                                                     
          .map(MultiaddrPeerAddress::fromAddress)                              
          .map(MultiaddrPeerAddress::getId)                                    
          .toList();                                                          
  final DirectPeerManager directPeerManager = directPeerNodeIds::contains;    
  peerScoringConfigBuilder.directPeerManager(Optional.of(directPeerManager)); 
  return this;                                                                
}                                                                                                                                                         

[Nashatyrev]

I would prefer to have it like below in the Config class:

public Builder directPeers(final DirectPeerManager directPeers)

It would allow more flexible (dynamic peer set) and typesafe (String is pretty ambiguous) programmatic configuration

[StefanBratanov]

I think it's a good place to add description similar to what will be in the docs, can mention they will be treated as explicit peers, not get downscored, etc

[Nashatyrev]

LGTM, just a minor suggestion

@StefanBratanov it probably make sense to add a couple of libp2p unit tests to check if the isDirect is handled correctly

[Nashatyrev]

I would prefer to have it like below in the Config class:

public Builder directPeers(final DirectPeerManager directPeers)

It would allow more flexible (dynamic peer set) and typesafe (String is pretty ambiguous) programmatic configuration

[thedevbirb]

Hey everyone, thanks for the detailed review and feedback! I hope I've addressed all your suggestions now:

• downstream propagation of direct peers has been refactored by converting List<String> into List<NodeId> as soon as possible, and then converting it into DirectPeerManager
• better description of "static" and "direct" peers has been added to the respective CLI options

I also added one little test to make sure the CLI option and the configurations do the right thing indeed.
You can look at the single updates in the related commits.

Thanks!

[StefanBratanov]

LGTM to me as well. Feel free to raise a docs PR as well and we will approve it.