Adapt to v1 contract interface and aggregate data

[shanejearley]

Referencing v1 interface output from #294 when merged. This will mostly affect fetching and displaying user stake and rewards (or just increasing stake, for compounding). Some fetching and computation will be moved in #256 so it will be worth coordinating with @hawyar when we get to that point. But, you will at least hand the same interface to @DemogorGod regardless of underlying implementation.

[ccali11]

Using this space to think out loud a bit (will edit to update ad hoc):

• Need an aggregator method to iterate over user accounts and check amount staked, where, and amount of rewards at each validator

[shanejearley]

You can develop this in your composable, but this will move to @hawyar's PR #256.

Note, it's just stake per address. Where and what validators is shared.

[shanejearley]

You can get specifics from the contract logs.

Distinct user deposits? Grab ManagerDistribution(address,uint256,uint256) events for address (user or manager contract for a reward distribution), amount, and time.

You care where specific deposits went? Use PoolDeposit(address,uint32,uint256,uint256) for address (user or manager contract for a reward distribution), pool ID, amount, and time.

See how PoolStaked(uint32,bytes,uint32[]) is used to listen to new events (pool ID, validator public key, operator IDs) in users.ts is for a general example, though your user detail queries mentioned above are not concerned with listening to new events.

[shanejearley]

ManagerDistribution should be most interesting, since this is either called after a user deposit or a pool manager reward.

PoolDeposit will be less interesting since rewards earned from all validators will be distributed to all stakers. So the answer to "where" your individual stake goes becomes "everywhere" as rewards are compounded.

[ccali11]

@shanejearley - Going to PR this now but left some specific implementation around rewards calculation out until we decide on what we want calculated where. Definitely down to do that in a separate PR (once we decide what we want to fetch/subscribe/listen to and where (FE vs BE)). Gained decent understanding of how to interface with SSVManager, which will allow me to more rapidly develop next related features, so that's a win imho.