Fix vote_generator loop inconsistency during high load

[guilhermelawless]

Adds a vote_generator_threshold config option ( between 1 and 12 ) and new logic for the vote generator loop. The goal is to make it behave like a deadline timer which is reset when new hashes arrive, and when fired sends the hashes.

• The loop still waits on a condition_variable for up to vote_generator_delay (50ms default)
• The cv can be notified by vote_generator::add when a new hash arrives, which makes the loop not send the votes yet, but wait for more. This happens when hashes are arriving fast.
• When the cv is notified, that means hashes are not arriving sufficiently fast, so the loop sends the votes

The addition of vote_generator_threshold helps in configuring what the "high load threshold" should be.

Approximate equation (assumes constant rate during sleep time): hash_arrival_rate * sleep_time = hash . By setting hashes to our threshold (default 3), and sleeping the default 50ms, we expect to enter the high load mode at a vote rate of 60. Above that number, if consistent, and we should only see packs of 12 votes. In reality it's lower, at 40 or 45.

So we can play with the delay and threshold to achieve a desired configuration. By default, anything below 40 tps and the node should not take more than 50ms to vote for a transaction. Above Around 40-60 it should take around 200ms, decreasing for higher hash arrival rates.

---

I've tested this pretty successfully on beta already. Would be interesting to see in RC5 if no issues arise. With a 100tps push of ~2000 blocks by Json:
117,63,0,0,0,0,1,0,0,0,0,176 , where the first number is votes with 1 hash and the last is votes with 12 hashes

[clemahieu]

What's the reason for it taking 200ms at 40-60 tps?

[guilhermelawless]

@clemahieu
First, 3 hashes arrive in 50ms (if less than 3 after 50ms we just pack and send).
Afterwards:

• the worst case for latency is one hash every 50ms. This would mean 50+50(12-3) = 500ms.
• the average case will see a constant hash arrival rate during the hash gathering period (3h/50ms), resulting in 12 votes after 200ms.

I should have said initially that if the rate is any higher than 3h/50ms then it takes less than 200ms, probably this is why you asked. There is no lower bound.

[cryptocode]

Looks good in my tests