Added reward-related functions to IApplication interface

[pdyraga]

Closes #89

The interface is minimal and does not enforce any specific requirements on how the rewards are actually accrued.

function withdrawRewards(address stakingProvider) external withdraws application rewards for the given staking provider. Rewards are withdrawn to the staking provider's beneficiary address set in the staking contract. Function emits RewardsWithdrawn(address indexed stakingProvider, uint96 amount) so that applications can easily track the total amount of rewards accrued so far.

function availableRewards(address stakingProvider) Returns the amount of application rewards available for withdrawal for the given staking provider.

[cygnusv]

Function emits RewardsWithdrawn(address indexed stakingProvider, uint96 amount) so that applications can easily track the total amount of rewards accrued so far.

Although this doesn't affect the PR, just to note that the RewardsWithdrawn event can only track rewards that were withdrawn, not accrued.

In fact, I just realized if it makes sense to make a differentiation about accrued rewards and withdrawable rewards, e.g., because some app has some specific logic that limits withdrawals. In other words, is it possible that there's a context where, for some application, availableRewards() < accruedRewards(), instead of availableRewards() == accruedRewards()? If so, is that something we'd want to generalize?

[pdyraga]

Function emits RewardsWithdrawn(address indexed stakingProvider, uint96 amount) so that applications can easily track the total amount of rewards accrued so far.

Although this doesn't affect the PR, just to note that the RewardsWithdrawn event can only track rewards that were withdrawn, not accrued.

Correct, that was my intention and I think it is reflected in the code in the current form. The PR description is misleading but I'll leave it as-is given we have this conversation here.

In fact, I just realized if it makes sense to make a differentiation about accrued rewards and withdrawable rewards, e.g., because some app has some specific logic that limits withdrawals. In other words, is it possible that there's a context where, for some application, availableRewards() < accruedRewards(), instead of availableRewards() == accruedRewards()? If so, is that something we'd want to generalize?

I am not sure if accrued rewards should be a part of IApplication, I would rather keep the interface minimal. It is possible some application may have such special cases, but I would leave it outside of IApplication interface. There is no way we can reflect all needs in the interface and every one function more means more pain with application contract size 😉

[dimpar]

I take that there's no need for a function in this interface that withdraws only a part of accrued rewards?

Also, I don't think RewardsWithdrawn event will be enforced in the implementation, something that the devs will need to be aware of and not duplicate.

[pdyraga]

I take that there's no need for a function in this interface that withdraws only a part of accrued rewards?

I would not impose such requirements on applications. We want the reward withdrawal to be as cheap as possible, hence the minimum interface. If some application wants to provide something extra, sure but outside of the "must-have" contract.

Also, I don't think RewardsWithdrawn event will be enforced in the implementation, something that the devs will need to be aware of and not duplicate.

There is no way we can enforce it on the compilation level but there is a @dev section in withdrawRewards docs that says this is the expected behavior.