deprecate BeaconBlocksByRange.step

[arnetheduck]

The step parameter has not seen much implementation in real life
clients which instead opt to request variations on a few epochs at a
time (instead of interleaving single blocks, entire epochs are
interleaved).

At the same time, supporting step on the server side brings several
complications: more complex bounds checking logic, more complex loading
of blocks from linear storage (which presumably stores all blocks and
not just certain increments).

This PR suggests that we deprecate the whole idea. Backwards
compatibility is kept by simply responding with a single block when
step > 1 - this is allowed by the spec and should thus be handled
gracefully by requesting clients already, should there exist any that
use larger step counts.

Removing step now allows simplifying the EL-CL protocol for serving
execution data from the EL to avoid double storage.

[djrtwo]

I'm happy to remove this (generally) unused optimization path.

The backwards compatible deprecation looks good to me but want to hear from client devs

[arnetheduck]

The corresponding execution API call is being proposed here: ethereum/execution-apis#218

[djrtwo]

I added this for discussion in the next CL call: ethereum/pm#527

[divagant-martian]

shouldn't we have a new protocol_id for this change?

[AgeManning]

@arnetheduck - As @divagant-martian suggests, wouldn't it be nice to increment the version at some point so we can remove the parameter all-together?

[arnetheduck]

@arnetheduck - As @divagant-martian suggests, wouldn't it be nice to increment the version at some point so we can remove the parameter all-together?

I would 👍 a PR but it's also a fair bit of coordination work, ie we'd have to ensure all clients implement then keep the old request around over a hard fork and get the new request implemented before.

The current wording requires that we return one block - the way I worded it makes it slightly ambiguous in that it doesn't specify what to do if the block at start is missing: should we return the first non-empty block that satisfies the non-1 step condition or return nothing? this should be addressed in such a PR - the latter interpretation effectively might turn into a backwards-compatibility issue if clients overinterpret empty responses.

[AgeManning]

Yeah, there is a small overhead. Like if each client just made a v2 and set it as a priority, no-coordination is needed. Once we hard-fork and know all nodes on the network have a v2, all clients in their own time can remove v1. So I guess the only co-ordination we need is that all clients should implement and prioritize a v2 before some hard fork.

Saves us very little bandwidth, but just seems like a nicer approach.