RFC: reduce data request latency by publishing tallies immediately

[aesedepece]

Current behavior

A tally transaction for a data request that is unsolved is currently accepted only in one of these cases:

1. A first block after the block in which the the reveals count matches the commitment count. This is the normal behavior.
2. A fourth block after the request enters reveal stage, if there are still missing reveals. This ensures an eventual tally even in the case of failure to reveal, or reveal censorship.
3. A fourth block after the request is published into the chain, if none of the blocks in between include a number of commitments equal to quorum / required witnesses count. This ensures an eventual tally even in the case of failure to commit, commit censorship, malformed requests, too high collateral requirement, sudden shrinkage of node count in the network, network partition, etc.

RFC

Case 1 can be modified to remove the "first block after the block" requirement. That is, if a block already includes enough missing reveals to match the number of commitments, a tally can be accepted in that same block.

In other words, data requests can go from reveal stage and to tally stage and finally to complete stage in the lapse of 1 epoch.

This shouldn't compromise any of the assumptions of the commitment scheme, nor introduce any opportunity for censorship from revealers or tally producers.

Moreover, this creates an additional incentive (tally fee) for miners to be the ones to collect and first publish all the missing reveals for each data request. — EDIT: we don't have tally fees anymore!

The effect of this change is that for the best-case resolution of a data request (1 commitment round + 1 reveal round), the total data request lifecycle will be reduced by 1 epoch (45 seconds), which is a far from negligible reduction for time-critical use cases.