feat: fix bugs with status command

[wadealexc]

1. fix a bug where we pulled the beacon state head even if we have an old checkpoint
2. fix a bug where we compute the wrong diff if the pod owner queues a withdrawal
3. still an outstanding bug: i think sumRestakedBalancesGwei also needs to use a prior state if we have an existing checkpoint

see comments below for explanation and testing

[wadealexc]

Sharing some screenshots displaying bugfix # 1.

Running status on our preprod test pod, which has had a checkpoint active since yesterday, the master branch shows:

As you can see, the master branch uses the head state. This branch downloads the correct state:

[wadealexc]

Bug # 2 explanation:

This bug occurs when the pod owner queues a withdrawal in the DelegationManager. The bug is that queuing a withdrawal results in a decrease of shares - so you had 32 ETH of shares, then you queued a withdrawal, now you have 0 ETH of shares.

When a checkpoint is completed in the pod, the change in shares is applied as a delta - so if you have gained 0.01 ETH, the checkpoint would add 0.01 ETH to your current shares, for a new total share count of 0.01 ETH.

The CLI bug here is that the master branch version computes your new shares as a total share value, rather than a delta. It sees that you have 32.01 ETH total assets, so assumes that completing the checkpoint will result in 32.01 ETH worth of shares. Since we have 0 ETH worth of shares at the moment due to our queued withdrawal, the master branch will assume that completing a checkpoint will result in a diff of 32.01 ETH.

The change in this PR correctly calculates a delta rather than using a total.

[wadealexc]

Bug # 2 testing:

To test this change, I am manually altering the value returned when the status command fetches currentOwnerShares (on both master and this branch):

https://github.com/layr-labs/eigenpod-proofs-generation/blob/4acc4b03c09df33855c6d97467476f563cc3508c/cli/core/status.go#L157

This effectively simulates running the status command after the user has queued a withdrawal for all their shares. Then, running status command on master yields:

As you can see, master assumes we can get 64 ETH worth of shares from a checkpoint. This PR fixes this:

[wadealexc]

Bug # 3 explanation:

If we have partially completed a checkpoint, status will not correctly compute the share diff for finishing the checkpoint. This is because it will base the beacon chain ETH delta portion of the share diff on the current checkpoint state, which has already ingested a few updated validator balances.

Those validators' balance diffs will not be accounted for in the delta the CLI calculates. To fix this I need to consider whether there's a way to use checkpoint.balanceDeltasGwei to correct the diff. Alternatively we can use the ETH rpc to read the pod's state when the checkpoint was started rather than partway through.

Not sure what's better here. TBH I think this is a fairly minor issue and the PR here is already a good improvement, so this might be something we want to earmark for a future fix.

[jbrower95]

PodBalanceGwei is the delta?

[wadealexc]

yep! it's calculated when the checkpoint is started on chain

[wadealexc]

probably couldve been named better 😬

[jbrower95]

I can clean this all up tomorrow. Your testing seems exhaustive, and I've run a few more scenarios on my side as well.