Updates to LIP-36 PR

[yondonfu]

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

Overall diff against streamflow branch.

The BondingManager bytecode size is now 23280. The size can be calculated with the following steps:

npm run compile
cat build/contracts/BondingManager.json | jq '.deployedBytecode' | wc -m | xargs -I {} echo "{} / 2 - 1" | bc

Specific updates (required)

• Cherry-picked a75e2b8 from streamflow to avoid dealing with rebase conflicts for now
• Fixed failing test cases in #390
• Re-use pendingStakeAndFees() helper in pendingStake(), pendingFees() and updateDelegatorWithEarnings()
  • This also means that the pre-LIP36 earnings claiming algorithm will no longer update the reward/fee pool and claimable stake for each round and that rewards/fees in a pool that are unaccounted for due to a delegator claiming before those rewards/fees are added to the pool will no longer be re-distributed to other delegators that have not claimed from the pool yet. After looking at the code some more, I agree with @kyriediculous 's point that the advantages of this change outweigh the disadvantages
• Reduce the diff for EarningsPool
  • Use separate updateCumulativeRewardFactor() and updateCumulativeFeeFactor() functions from EarningsPoolLIP36
  • Remove deprecated functions addToRewardPool(), addToFeePool() and claimShare() from EarningsPool
• Remove unneeded storage update for activeCumulativeRewards in updateTranscoderWithFees()
• Updated ethlint config and fixed all warnings/errors
• Reverted a few temporary changes

May still be useful to add additional tests, but left that out for now.

How did you test each of these updates (required)

Ran test suite.

Does this pull request close any open issues?

N/A

Checklist:

• [x] README and other documentation updated
• [x] All tests using npm run test pass

[yondonfu]

f53c96a Fixes a failing test case related to updating activeCumulativeRewards in updateTranscoderWithFees ab87bf6 Always sets lastFeeRound to the current round since its possible (although unlikely in practice due to the way the client is implemented) for a ticket to be redeemed with round N and then a ticket to be redeemed with round N - 1.

[kyriediculous]

Ran some tests and changes look good to me otherwise , just needs a npm run eslint:fix it seems.