feat(Rewards): add mintBatchReward

[aliXsed]

In this implementation I have defined the struct BatchReward as:

    struct BatchReward {
        address[] recipients;
        uint256[] amounts;
        uint256 sequence;
    }

assuming recipients[i] corresponds to amounts[i]. This means we expect recipients.length == amounts.length. That's why mintBatchReward needed to check this assumption. The reason I have gone for this design was to avoid using nested types which could make digestReward more complicated and costly. digestReward is needed for checking the signature.

[ETeissonniere]

No real comments, just whitespacing (we don't need one space between every line :D) and one open question on a double for loop which might be optimizable

[ETeissonniere]

We can avoid the double for loop here (other loop in _batchSum) by rewriting the for iteration and add one last revert statement afterwards

[aliXsed]

I tested the potential gas saving in your suggestion and found it either absolute zero or very negligible (less than 0.1%). While checking first and minting later has the benefit of early failure (gas saving there) and follows the best practice of updating state first before calling into any other contract.

[ETeissonniere]

Makes sense, let's keep it as is