WIP: Include multichain tests in Jenkins build

[pimveldhuisen]

See if multichain tests succeed in Jenkins and expand them/create pretty pictures

[synctext]

@NielsZeilemaker @pimveldhuisen and @ Ewout (please leave your accountname here)

This is the new PR for the multichain community. Two new students are taking this over, after Steffan defended his thesis work last week. #1429 is depricated.

We need a list if items to address and merge this work. Read Niels his comments and add:

• fix the re-introduce candidate bug in the gumby experiments.
• dramatically reduce the blocksize and checking interval from 1 MByte and 1 second. 100MByte and 1 minute check should be much better choices.
• disable community by default, no autoload.
• the usual squash commits operation

Still on the ToDo list are the SignAnything feature, planned for after this PR. Crawler code needs improvement and next task is making each community member collect records using a random walk.
Finally, adding resilient to Sybil attack using novel random walk idea using genesis blocks.

[whirm]

Delay the squashing as much as possible so you don't mix up your changes with the already existing ones, it will make your life easier.

[whirm]

Also undo the merge from devel and do a proper rebase instead.

[synctext]

another future feature: edge traversal needs churn resilience, keep-alive to barter partners.

[pimveldhuisen]

The SignAnything policy is not currently viable because your own total is calculated based on the data from the request. This should be done based on your own counters.

[Captain-Coder]

@pimveldhuisen I fixed the candidate bugs in the gumby experiments. You should expect a PR asap.

[Captain-Coder]

Discussed the session counters with @synctext. They reset when someone restarts the client, leading to inconsistent state (or opinions of how much up and download there has been). @synctext refuses to store the session counters in a database, since this is not simple. Dito for keeping timestamps in the counters. Thus I suggest applying a decay to the counters. A percentage decay every so many seconds/minutes/hours with a minimal threshold before deleting the counter. Easy to implement and doesn't add state. Such a decay means that long running clients will eventually converge to 0, the same state that new or restarted clients have.

[whirm]

I guess these counters are per MID right? what's so hard about keeping a table that holds (MID, last_contact, counter) and gets cleaned up every now and then? Am I'm missing something?

[synctext]

@whirm @Captain-Coder
Yes, we can do simple accurate counters later. For now I think the best approach to get a mean&lean version deployed. As long as it "does no harm" to Tribler.

Then we can measure it, understand how it functions, and can incrementally improve it in various sprints.

[whirm]

Do a rebase against devel, you are mixing up commits from devel with this branche's and it will be hell for you to fix afterwards.

[pimveldhuisen]

Superseded by #1843