Light client updates by range rpc and add LightClientHeader

[GeemoCandama]

Issue Addressed

#3651

Proposed Changes

• Add LightClientHeader and use it in place of BeaconBlockHeader in the other light client structs.
• Make the LightClient update constructors reflect the spec more because the current implementation avoids some checks outlined in the spec.
• Add is_better_update function for LightClientUpdates
• Outline LightClientUpdates rpc
• Add LightClientUpdates DBColumn to the db indexed by sync committee period and add migration file
• add get_light_client_update and put_light_light_client_update and use them to complete the rpc
• add is_better_update tests (I think there is a standard set of tests)
• add tests for LightClientUpdate rpc
• use proper db iterator in request handler

Additional Info

The database stuff is confusing for me but I think I'll have time to finish this PR by the end of the week.
EDIT: Would this be better as two separate PRs?

[GeemoCandama]

The test I did for the update_ranking ef_test is a bit awkward because it doesn't follow the pattern of many of the other tests. I am comparing each update to eachother twice but with the updates in opposite order. I used a wrapper struct around bool to use the sweet sweet procedural macro for CompareFields. Let me know if you want this changed.
EDIT: I'm setting this to ready to review because to make the tests work for the rpcs will require a lot of code. I'll make another PR if you want testing. Also, I'd appreciate a bit of assistance using the appropriate db iterator.

[dapplion]

This PR implements the wiring for ReqResp method light client updates, but does not produce the necessary messages. The wiring part is correct, but merging as-is would add a route that will always return resource not available.

The store methods make some assumptions on how updates are produced, i.e. using the split to store in either hot / cold. That may not be necessary in a progressive lightclient server (compute updates eagerly).

I would put this PR on ice, implement the message producing logic, and then wire the network based of these commits.

[dapplion]

Is this used?

[jimmygchen]

This branch is now quite outdated, and we've made quite a bit of progress on light client server, and it might be easier to close this one and start from scratch, what do you think @eserilev ?

[dapplion]

Most of the outstanding changes of this PR have been covered in other light-client PRs, closing. Thank you so much @GeemoCandama for initially driving this effort forward! It's on us to take too long to dedicate bandwidth to this.