Disconnect nodes with bad messages during IBD #18760

Fixes #18755

นัม

Can you explain why you'd want to disconnect a good peer during ibd when there was a bit flip during transmission?

Also the tests fail

Also the tests fail

Thank you. I'll look into this.

Can you explain why you'd want to disconnect a good peer during ibd when there was a bit flip during transmission?

because it fixes the issue #18755 in the simplest way possible is the short answer. What would you prefer as a solution?

The only other options I can see, which is more complex, would be to keep some connected nodes on standby, not downloading during the IBD, so that when something like this happens, they can be ready to respond and provide the blocks needed most urgently (in order not to delay IBD), as the other nodes downloading will be queued up to download more recent blocks.

Another option, less ideal but simpler, would be to identify the block that failed, and immediately class it as no longer in flight, so that it gets added to the download queue again, albeit delayed as it will need to wait for the more recent blocks to have downloaded first.

This solution (in this pull request) assumes there is little value in keeping the node that delivered the corrupted block connected. Is there a value in keeping the connection open that I am not aware of?

For example, there are already places in the code where the simplest way to deal with things is disconnection, e.g. when blocks are requested that have been pruned, and probably other examples also, so disconnection already seems to be an accepted practice in order to expedite IBD when things go wrong.

closing until tests fixed