### Double trouble

Pools are farms that accept user deposits. Pools themselves are particiapting in a "master" farm that pays out rewards to all other pools.

Whenever a user calls `claimOnPool()`, the pool goes to master farm to `claimOnMaster()` their reward. Previously, constant weights are represented as shares in the master farm. All pools have the same epoch as the master farm (eg. per block).

> updatePool() is the function that updates `accumulatedRewardPerShare`

Advantage(s):
* Over time, as new pools get added, it is not necessary to call updatePool() on all pools (as opposed to constant weights)
* To calculate the rewards that need to be sent one pool is more efficient. Now, even a user could afford paying for that as opposed to an admin.
* when sending back the "time reward left-over" to the master farm, even a user could pay for the transaction cost to extend the farm. (this idea needs to be thought through)
* It keeps track of rewards that are supposed to be sent to the other pools, even though one pool interacts with the master farm algo
* One pool cannot take away rewards of another pool