Support LightClientFinalityUpdate and LightClientOptimisticUpdate rpcs

[GeemoCandama]

Issue Addressed

#3651 partially addresses

Proposed Changes

Support LightClientFinalityUpdate https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/p2p-interface.md#getlightclientfinalityupdate

Support LightClientOptimisticUpdate https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/p2p-interface.md#getlightclientoptimisticupdate

Additional Info

I didn't name it GetLightClientFinalityUpdate to follow the LightClientBootstrap PR that has been merged already #3711. I'll make another PR to support LightClientUpdatesByRange as it's a bit more involved.

[divagant-martian]

I discussed this with @pawanjay176 and we might want to split the protocol modeling for asymmetric protocols before including these, FYI. Pawan is looking into this. If he doesn't have the bandwidth I might get to this at some point

[GeemoCandama]

Should be good now. I was trying to keep the branch up to date with the changes and I didn't realize that the changes broke it. Also I added a full match to the context_bytes function so it will give more compile time feedback, since I didn't realize that I needed to make those changes until after a bit of hunting.

[divagant-martian]

there are some conflicts. Would you mind looking into those and then I'll trigger ci for you

[GeemoCandama]

conflicts are fixed now. EDIT: Clippy was the only that failed and I think I appeased clippy now, but when I ran clippy locally last time I didnt get any errors either so I am not certain.

[pawanjay176]

Hi @GeemoCandama , I had a look at this over the weekend. It's looking good. I'm gonna spend some time this week to see if the MockRpcHandler can be simplified. Sorry for the delay.

[jimmygchen]

Thanks @GeemoCandama for your work on this! I'm going to pick this one up and try to push it over the finishing line!

[jimmygchen]

The network wiring of this PR is correct, but half of the diff is a mock to test the light-client network server. ..

Yep agree with the above, also mentioned your suggestion to @michaelsproul last week - we think it's a good idea. The current mock-light-client pretty much need a re-write because of the rust-libp2p upgrade - I've made an unsuccessful attempt a few weeks ago, and that got me into asking myself the same question on whether we should come up with an alternative - I then started building a light client consumer prototype for this, but haven't got it to a usable state.

[jimmygchen]

Blocked by #4926

[jimmygchen]

I've made some updates to this branch and I think it's in a good state for review. I'd probably wait until we get #4946 merged in first, though.

We should also add some tests for this (#4940), I'll get to it when I have some time.

[jimmygchen]

I've merged in latest unstable. I haven't been able to test this in a real network as we still haven't implemented the LightClientUpdates req/resp interface. I think we can merge this as it is after review, as it doesn't touch the default code path (requires light-client-server flag).

[jimmygchen]

@mergify queue

[mergify[bot]]

queue

✅ The pull request has been merged automatically

The pull request has been merged automatically at 32be063f0f8cc9b1dfc46da1e583ec99f232253f