Active sets => Rewarded + Active/Idle sets

[jstuczyn]

This pull request is more or less ready, however, it cannot be merged until #856 has already been merged as it builds on the changes in there. Therefore it shall remain a draft until that happens.

Will close #2103

This pull request extends the concept of "active sets" into concepts of "rewarded" and "active sets".

"Rewarded" set is set of mixnodes based on the currently demanded bandwidth. It is expected to be only changed once per rewarding interval. It includes the mixnodes that are going to receive rewards during this rewarding interval. This set is then further subdivided into "active" and "idle" mixnodes.

"Active" mixnodes indicate nodes that are going to be doing any work. They can be updated more frequently, such as every one hour, in order to deal with current demand fluctuations.

Note that only "rewarded" nodes are being tested by network monitor. The rest of the nodes are completely ignored.

Special care must be taken when merging #833 <= ensure correct nodes are rewarded and tested.

After this PR is merged (or even before) another one needs to be created that actually updates the value of rewarding_interval_starting_block so that different seeds would be used during different epochs.

In order to transform this draft into a proper pull request the following is still required:

• determine "demanded" nodes in the validator API only when explicitly required -> this will get us one step closer to doing so deterministically among multiple validator APIs
• send network monitor test packets only through the "rewarded" nodes. We don't care about ALL the bonded nodes on the network anymore,
• determine the "demanded" and "active" sets with weighted pseudorandom selection
• Ask Claudia about what should be done with the gateways in that case - should we test all / any of them? -> Dave says it's useful to have uptimes for the gateways even if we don't reward them directly
• Make sure only correct set of nodes are rewarded and with correct amounts. I might perhaps need to have a chat with @durch to discuss integration with his branch. I.e. make sure "active" nodes(and its delegators) get full rewards, while "idle" nodes get only some part of it. - this should be done as a separate PR instead
• Introduce BeginRewarding and FinishRewarding transactions that would update contract's rewarding_in_progress and rewarding_interval_nonce values respectively. If it's an easy change, rewarding_in_progress would also lock any delegations in place to help us deal with any weird edge cases. - this should be done as a separate PR instead