Peer list is not consistent tested with small network

[helderjnpinto]

Description

As a blockchain client validador or not i want a list of a peers of my network not in duplicated and more consistent.

Acceptance Criteria

• In small network (we talk about 4 validators) only of validators should by a consistent count between all peers
• Not have duplicated nodes (like filter by enode public key and ip)

Steps to Reproduce (Bug)

• I made a setup local with multiple clients using docker-compose below i will put my findings.

In the following tests i made with same group of validators that is composed by:
1 bootnode + validator IBFT 2.0
3 validators IBFT 2.0

Test 1 - Testing only a small group of validators

This result some times give the same amount of peers should be 4 on each of them that i think it is correct i suppose.
working dockers more than 30 min.

Test 2 - Testing only a small group of validators + clients

Some result as test 1 the peers count never is equal working time > 1h.

Test 3 - Testing validators + clients with other parameters

some of the peers have duplicated peer enode but network property have different ports (at first time i thought maybe is a docker-compose thing) but when i checked my aws network i also have duplicate enodes and this exists in different pods.

Additional Information (Add any of the following or anything else that may be relevant)

• Besu version is 21 (this bug is present in older versions) I tested this to try solve the other issue IBFT2.0 peer connecting issue when multiple Ethereum clients try connect to bootnodes #2011
• Linux l480 5.13.0-39-generic 20.04.1-Ubuntu SMP Thu Mar 24 16:43:35 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

• i5, 16 GB RAM.

[frankisawesome]

Thanks for the detailed report - this is a known issue that's currently in our backlog, we had a draft PR up but other priorities came up so it's pending further work, we'll use this issue and report back once progress is made.

Feel free to look at the draft pr in the meantime #3383

[macfarla]

For clarity @helderjnpinto we are closing this issue as a duplicate - this will be addressed as part of the work for #2689