Rep crawler overhaul

[pwojcikdev]

Initial motivation for this PR was providing better control over rep crawler component lifetime and running its internal logic on a separate dedicated thread. In the process of working on it I made many smaller improvements that should make the logic clearer and less error prone.

Testing results provided by @gr0vity-dev show that performance is on par with current develop.

[pwojcikdev]

I made a few adjustments based on recent network stress test. It should make repcrawler a bit better at finding representatives when vote requests are unreliable.

develop

rep-crawler-overhaul

[pwojcikdev]

With the latest commit running on live network, rep crawler averages about ~6 requests per second with response rate of about 25%. It is able to keep a stable peered stake.

[dsiganos]

I am trying to understand how multiple reps inside one node would be dealt.
So I created this test case and it fails:

// Test that nodes can track PRs when multiple PRs are inside one node
TEST (rep_crawler, two_reps_one_node)
{
	nano::test::system system;
	auto & node1 = *system.add_node ();
	auto & node2 = *system.add_node ();

	// create a second PR account
	nano::keypair pr1 = nano::test::setup_rep (system, node1, node1.balance (nano::dev::genesis_key.pub) / 10);

	ASSERT_EQ (0, node2.rep_crawler.representative_count ());

	// enable the two PRs in node1
	system.wallet (0)->insert_adhoc (nano::dev::genesis_key.prv);
	system.wallet (0)->insert_adhoc (pr1.prv);

	ASSERT_TIMELY_EQ (5s, node2.rep_crawler.representative_count (), 2);
	auto reps = node2.rep_crawler.representatives ();
	ASSERT_EQ (2, reps.size ());
}

[pwojcikdev]

@dsiganos Good catch, feel free to commit this testcase. I'll look into solving it.