confirm pivot block - removed disconnect based on chain height estimate

[macfarla]

PR description

When choosing the "best" peer to try to confirm the pivot block

• ~~use the default comparator (TTD then chain height)~~ effectively the same
• remove the pre-requirement for the chain height estimate
• don't disconnect the "worst" useless peer at this point
• and update the peer's chain height estimate if the pivot block is confirmed
• also allow 5 peers below the pivot block height since the chain height estimate we use for comparison can be wildly inaccurate

Fixed Issue(s)

Fixes #6887

Thanks for sending a pull request! Have you done the following?

• [ ] Checked out our contribution guidelines?
• [ ] Considered documentation and added the doc-change-required label to this PR if updates are required.
• [ ] Considered the changelog and included an update if required.
• [ ] For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• [ ] unit tests: ./gradlew build
• [ ] acceptance tests: ./gradlew acceptanceTest
• [ ] integration tests: ./gradlew integrationTest
• [ ] reference tests: ./gradlew ethereum:referenceTests:referenceTests

[macfarla]

3 EthPeers {
PeerId: 0x3bd1127b27212d2d... 1297018 height (est) PeerReputation score: 97, timeouts: {1=4, 3=1}, useless: 0, validated? true, disconnected? false, client: erigon/v2.58.1-f12e451c/linux-amd64/go1.21.7, [Connection with hashCode 820003208 inboundInitiated? false initAt 1712461468564], enode://3bd1127b27212d2d165ffaa7ae1e0efbdfdf7ff2022e851dc95271e44bb271446ab05e54035756da7eb6ce86b595992d94f2400ed19a34d9485df81fc12d0879@147.28.163.12:30304, 
PeerId: 0xac906289e4b7f12d... 1296969 height (est) PeerReputation score: 150, timeouts: {}, useless: 0, validated? true, disconnected? false, client: Geth/v1.13.14-stable-2bd6bd01/linux-amd64/go1.21.7, [Connection with hashCode 1951103145 inboundInitiated? false initAt 1712461466663], enode://ac906289e4b7f12df423d654c5a962b6ebe5b3a74cc9e06292a85221f9a64a6f1cfdd6b714ed6dacef51578f92b34c60ee91e9ede9c7f8fadc4d347326d95e2b@146.190.13.128:30303, 
PeerId: 0xa3435a0155a3e837... 1297002 height (est) PeerReputation score: 150, timeouts: {}, useless: 0, validated? true, disconnected? false, client: Geth/v1.13.14-stable-2bd6bd01/linux-amd64/go1.21.7, [Connection with hashCode 455188871 inboundInitiated? false initAt 1712461466663], enode://a3435a0155a3e837c02f5e7f5662a2f1fbc25b48e4dc232016e1c51b544cb5b4510ef633ea3278c0e970fa8ad8141e2d4d0f9f95456c537ff05fdf9b31c15072@178.128.136.233:30303}

[macfarla]

2024-04-07 13:45:03.763	
trailing peer requirements TrailingPeerRequirements{minimumHeightToBeUpToDate=1296943, maxTrailingPeers=5}

2024-04-07 13:45:03.763	
trailing peer requirements TrailingPeerRequirements{minimumHeightToBeUpToDate=0, maxTrailingPeers=9223372036854775807}

[macfarla]

I started 3 holesky nodes last night - 2 of 3 did really well, the third one dropped to zero peers (this seems to happen on holesky, workaround is to add the 2 bootnodes using admin_addPeer so they effectively become static peers). The first 2 still have 25 peers and the third one still has only 2 peers (the bootnodes) <- I have seen this on holesky independent of this PR (maybe worth investigating as a discovery issue separately but I don't think it's high priority)

holesky sync also fine (once the zero peers node got peers, it quickly got back in sync)

[macfarla]

2 x mainnet nodes started today, one took a long time (more than 5h) to find peers - mainnet-sally-6889-07 - currently on 24 peers. Both look to be syncing fine (so far)

sync progress

[macfarla]

this has been incorporated into #6968