Active elections loop tuning

[guilhermelawless]

Closes #2137 , closes #2139 (alternative to both)

Todo

• Adjust frontier confirmation mode timings with the decreased elections size and loop time
• Allow a certain time for low-difficulty elections before flushing
• Split into smaller, contained PRs Basic confirmation request loop enhancements #2327

Documentation

• active_difficulty updates are now done every ~500ms (give or take), and not 16-36 seconds

PR Description
This PR has 2 main changes:

• Disables per-block confirm_req in the block processor
• Changes the confirmation loop such that it has a period of 0.5s instead of 16-36 seconds.

Other things had to be tuned consequently, such as frontier prioritization timings. Data collected on the beta network shows there are large improvements to bandwidth usage under high load, much more agile PoW prioritization, and reduced tcp write drops.

The optimized bandwidth allows for doing a larger number of batch confirm_req directly to representatives in the same amount of time. The PoW prioritization being more agile means even under saturation the network should correctly prioritize blocks with the highest PoW such that those are confirmed fastest.

The active elections container is reduced to 10k soft maximum. As blocks arrive that would immediately be dropped due to a low work difficulty, the election is allowed to live for up to 10 seconds, after which it is dropped.

There is a minimum time of 1 second until an election is considered for confirm_req, and the same time for being consider for active difficulty.

Future improvements

• Using a passive elections container to store a larger amount of elections that would otherwise be dropped. If the size of a passive election is small and not many operations are performed on the container, it can possibly be in the order of 100k in memory.

• Consider not rebroadcasting votes if the node is saturating, at least for blocks that would go into passive elections. This means all blocks would be confirmed via confirm_req. A better alternative would be Vote stapling #1006 . Currently, even under saturation, there's a chance that blocks are confirmed via live elections even if they have a low PoW difficulty.

Acknowledgments
Thanks to @Srayman for the enormous help in tuning and testing, and @Joohansson for the blocks.