Try2: ExecutionProofsByRange + persistent proof storage

[kevaundray]

Issue Addressed

Which issue # does this PR address?

Proposed Changes

Please list or describe the changes introduced by this PR.

Additional Info

Please provide any additional information. For example, future considerations
or information useful for reviewers.

[kevaundray]

We likely also want to remove "already_seen" from ProofsByRoot since that is only going to be used for historical blocks, ie nodes can just send us everything. I was hoping to be able to ask one node for one proof and then another node for a different proof for the same block, but I think we can just apply this optimization afterthefact, moreso given the networking folks will likely have better takes on what to do here

[kevaundray]

Although we have ExecutionProofsByRange the missing component is integrating it into range sync which seems a bit involved

[kevaundray]

Something to flesh out: How do zk attesters interact with non-zk attesters on the network? Does the network topology overlap?

Notice that if all zk attesters only talk to zk attesters and they all don't have the proof, then range sync does not kick in, because no node will be far ahead