hbbft automatic reserved peers management

[SurfingNerd]

HBBFT uses direct connections between the the different nodes that cooperate to produce a block.
Open Ethereum allows to define a list of reserved peers.
This can be achieved using different ways:

• reserved peers text file
• parity API: parity_addReservedPeer see documentation
• start up command line arguments.
• dynamicly get connection to specified public key using the p2p node discovery.

for testing the current client versions,
we used the configuration file method for defining the reserved peer.

This means, dynamicly adding an Node also required to add this node's eNode to all reserved peers configuration file.

This could be automated by the hbbft engine implementation, since the hbbft engine knows the public key to interact with from the HBBFT POSDAO contracts.
A support for IP Addresses is also prepared in those contracts.

split up into 2 implementation checks:

• 1: adding all conensus peers.
• 2: adding current and pending validators only / removing peers that are not part of the hbbft set anymore.

Also, since this requires to store the Nodes IP and Port information on the blockchain, and the Validator Node is the only one that is able to write, and at most one validator must run with the Validator Node key unlocked, we can asure that the information on the blockchain is exactly our last write call to this.
Therefore we do not need expensive read operations for the current IP over and over again.

[SurfingNerd]

Alpha Testnet has shown that it is possible without that, as long there are enough peer slots.
Like 12/25 peers means that are still 13 unused peer slots.
Adding the validator peers as reservered peers did not greatly improve the stability of the peers.
Maybe reevaluate this when the network is more stable.

[SurfingNerd]

OK, after further investigation, we could manage to restart a stuck network declaring the correct reserved peers.
We had reserved peers included, but the public key in the enode-id was wrong in same cases.

[SurfingNerd]

same problem caused the network stuck at block 33094. priorizing the issue now.

[SurfingNerd]

Implementation memo:

NetworkService::add_reserved_peer()
host::add_reserved_peer()

[SurfingNerd]

in development rust code: https://github.com/dforsten/openethereum-3.x/tree/dforsten/manage_network_access

Node Management upgrade are deployed on the testnet.: https://github.com/SurfingNerd/hbbft-posdao-contracts/tree/i126-enode-management

SurfingNerd/diamond-contracts-core@845a010

[SurfingNerd]

for gathering the information of the current used IP address, the BlockChainClient does not has access to the NetworkService that would have access to a Host that would know the NodeEndpoint.
NodeEndpoint holds the IP and Port information, and is part of DevP2P.
EthSync has access to the network service, but only the entry point has access to it.
Client has access to the NetworkService because of ReservedPeersWrapper, and Client Setup is the last Step in the setup procedure.
Since 'Client' is a 'BlockChainClient', we can extent this Interface for gathering the required IPv4 and Socket.

[SurfingNerd]

4e975e3690c0ee424193e714d0ceec7aedc22b03 runs into a deadlock when connect_to_validator_core

[SurfingNerd]

fixed with 51bb99c423ce758f508567c08b172a1fabd7b6e5

[SurfingNerd]

works fine, but sometimes takes some time.
the reason why it takes some time is currently unknown.
will have more details available once we implement the devP2P monitoring. DMDcoin/diamond-node#25