Restore stability of peers blacklists and disconnections in Network Tests - Closes #2670

[diego-G]

How to test it?

npm test -- mocha:default:network

Review checklist

• The PR resolves Restore stability of peers blacklists and disconnections in Network Tests #2670
• All new code is covered with unit tests
• All new code was formatted with Prettier
• Linting passes
• Tests pass
• Commit messages follow the commit guidelines
• Documentation has been added/updated

[MaciejBaj]

What we've agreed to change is:

• To test disconnect/connect, rely on open connections numbers, but not strictly - should.be.above is enough as the connections with other peers are just propagating
• Due to the indeterministic propagation of connections with other peers after executing connection/disconnection network tests, checking the number of open connections with the other peers is pointless while testing peers blacklist. Check only the "BANNED" state while blacklisting.

Both of those conclusions are not introduced.
Peer disconnection tests are still relying on the strict numbers, but now the timeout is extended from 2 to 4 blocks, peers blacklists are still checking the number of connections, not the statuses only.

[diego-G]

@MaciejBaj every existing test is meaningful. Remove them or skip them is not the solution. The idea is to reduce the strictness on those problematic tests but, as less as possible while keeping a good balance in between test execution timing and stability. As you can realise the Jenkins trend build, I have found a good stability. It is reasonable and stable to be merged.

I want to state again this test suite is very useful for developers. It just needs more love. We should plan to seriously improve it for the future. Several points to perform are:

• Execute every test independently from each other : i.e, reinitiated the network completely after every scenario
• Execute scenarios in parallel to speed up the process : right now they are being executed in sequence over the same network. We might create several networks, for instance 1 per well-defined scenario.
• Review the design from scratch and find more and better use cases
• When a test failure occurs, gathering more data from the network status to reproduce the case and debug it