Make a list of wit/2 remainders

[aesedepece]

I started working on a list of everything that is broken, missing or lacking in the wit/2 branches.

This issue will track the completion and publication of such list, and will host the discussion on where to draw the line between what falls into the first witnet-rust 2.0 release candidate and what's left for subsequent release candidates to be released while already in testnet phase.

[drcpu-github]

Here is a list of items which I think are required for the Witnet 2.0 release:

• [x] A way to handle data requests which require too many witnesses. This can either be refusing to include such a data request in a block or creating a Tally with an error. The former has as an issue that, technically, these data requests stay in the mempool forever and the requester will never get a response (unless the centralized bridge short-circuits it, but that's not the nicest solution).
• [ ] A way to track active validators. In my opinion this is absolutely required to prevent griefing attacks where an attacker would purposely stake on inactive validator addresses to disrupt superblock consensus. I also think somehow using this active validator set would improve data request processing or even block proposals.
• [ ] An easy way to check the withdrawer associated with a validator for easier staking transaction validation (see https://github.com/witnet/witnet-rust/pull/2472/commits/059b6aa4a30b64cc9b30a573306e7d263073c00a).
• [ ] Data request resolving using the staking validators.
• [ ] Incrementing the stake with the block reward and received fees (see https://github.com/witnet/witnet-rust/pull/2472/commits/5781fc2dcbb79489b768d5f7e5d03293a09accf8).

Ideas for a Witnet 2.1 release:

• [ ] Implement a slashing mechanism for nodes that are not voting on a superblock. Slashing should probably only happen when there is no superblock consensus.
• [ ] Profit sharing between a validator and a designated second address similar to how the current block reward splitting already works. This can be used as a way to enabled delegated staking where the validator operator receives part of the reward from the staker.