Add reward caller (using transcoder-to-reward caller mapping direction)

[SidestreamSweatyPumpkin]

What does this pull request do? Explain your changes. (required)

This PR adds a new feature to the livepeer protocol which will allow transcoders to set a single address they trust to claim the rewards every on round without requiring the main wallet to stay unlocked.

Specific updates (required)

• contracts/bonding/BondingManager.sol contract is modified to include
  • New transcoderToRewardCaller public mapping
  • New setRewardCaller function to set or unset a rewardCaller
  • New rewardForTranscoder, rewardForTranscoderWithHint functions to claim rewards using rewardCaller account
• test/unit/BondingManager.js test is modified to include new "reward delegation" section
• yarn test:coverage:check command is added to the CI to insure 100% test coverage

How did you test each of these updates (required)

A new "reward delegation" section contains tests that ensure:

• A transcoder is able to to call the reward even if RewardCaller is set for them
• If a RewardCaller is set, the account is able to call rewardForTranscoder
• If the RewardCaller is unset, it no longer able to call rewardForTranscoder
• Checkpoint logs reward recipient, not the RewardCaller

Does this pull request close any open issues?

No

Checklist:

• README and other documentation updated
  • No relevant documentation found, the changes are backwards compatible
• All tests using yarn test pass

[SidestreamSweatyPumpkin]

Additional notes on the implementation

Note-01:

It is possible for a transcoder to set the RewardCaller as themself and call functions designated for RewardCallers. By doing so, the transcoder itself will be able to use the rewardForTranscoder and rewardForTranscoderWithHint. But other than being able to call both functions, there is no security risk identified. Note: we didn't include this edge case in the tests as this is not intended use-case.

Note-02:

It is possible for a TranscoderA to set the TranscoderB as RewardCaller. In this case, TranscoderB will be able to claim reward for themself by calling reward() and can claim reward for TranscoderA by calling rewardForTranscoder(TranscoderA). We didn't identify any security risk associated with this edge case.

Note-03:

In this implementation it is possible that multiple different transcoders set the same address as their RewardCaller. It will allow the same RewardCaller to call rewardForTranscoder(TranscoderA), rewardForTranscoder(TranscoderB) or even use multi-call functionality to save on gas.

Note-04:

It is not part of the current implementation, but it's possible to add a functionality to self-revoke RewardCaller. Currently, only the transcoder which set the RewardCaller can unset it by calling setRewardCaller with a different (or a zero) address.