Make threshold configurable for TreeOverlay

[youngjoon-lee]

Based on PR #425

Like FlatOverlay, we should use 100% leader threshold for TreeOverlay as well (for testing) because we don't have the block catch-up mechanism yet.

[youngjoon-lee]

Previously, FlatOverlay was using floor(), and TreeOverlay was using x * 2/3 + 1. I thought it's better to have a common function like this and chose to use ceil() to guarantee that the threshold is never smaller than the super majority.

[danielSanchezQ]

Nice, thanks!

[youngjoon-lee]

I'm not merging this PR now because CI fails, and I'm not sure if this failure is caused by this PR or not.
Test Suite (waku, ubuntu-latest)

waiting... 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0
waiting... 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0
waiting... 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0
waiting... 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0
thread 'ten_nodes_one_down' panicked at 'timed out waiting for nodes to reach view 20', tests/src/tests/unhappy.rs:25:24

This isn't even reproduced in my local.

[youngjoon-lee]

I'm not merging this PR now because CI fails, and I'm not sure if this failure is caused by this PR or not. Test Suite (waku, ubuntu-latest)

waiting... 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0
waiting... 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0
waiting... 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0
waiting... 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0
thread 'ten_nodes_one_down' panicked at 'timed out waiting for nodes to reach view 20', tests/src/tests/unhappy.rs:25:24

This isn't even reproduced in my local.

I've also found that the same failure sometimes occur in the ten_nodes_happy test. I'm debugging it.

One interesting thing is that the failure is not reproduced in my local (A Macbook with 10 cores), but it's reproduced in my Ubuntu VM (with 2 cores) in my Macbook, which has the similar resources as Github Actions hosts.

[youngjoon-lee]

I've also found that the same failure sometimes occur in the ten_nodes_happy test. I'm debugging it.

One interesting thing is that the failure is not reproduced in my local (A Macbook with 10 cores), but it's reproduced in my Ubuntu VM (with 2 cores) in my Macbook, which has the similar resources as Github Actions hosts.

I'm debugging this at #440. From my understanding so far, this failure is not highly related to this PR. But, I'm not sure yet.