les: add flag to configure les recent available state

[s1na]

It is an expensive operation for light servers to search for unavailable state requested by light clients. Hence LES came with a heuristic of rejecting requests if they were older than 128 blocks. The exception is for archive servers which have all state available. That works fine. But if a full node sets --gcmode archive periodically and have some older states available they still won't be served to light clients. This PR makes the number of recent blocks to check requests for configurable through CLI.

Note that there are 2 guards against this. First, during handshake the server announces a serveRecentState value which clients check before making a request. Second, even if the client sends a request the server itself double-checks and rejects requests for stale state. I added one flag for both of these cases. If you think they are different and need separate flags happy to change it.

Fixes #25235

[rjl493456442]

Personally I think this flag is very hard to use.

• If the node is fully archive(all states available), then all the states will be searched anyway
• If the node is not archive, then only the most recent 128 states will be searched
• if the node sets --gcmode archive periodically and has some old states, it means from the configured block until head, not all states are available.

For the third scenario, it will lead to some unexpected behavior: clients will make the requests but servers can't serve them. Eventually the connection between client and server will be dropped.

Apart from that, it's not easy for server operators to know what's the range of states for advertising.

[s1na]

@rjl493456442 My use-case is the third scenario. I didn't know requesting too many unavailable states will lead to dropping the peer that's a good point.

I realize this whole PR is very tailored to how I am using LES and might not be useful for other end-users. I know which states are available on my node and can set that in the flag.

Another idea might be to have --light.disregardRecentState on the light client side to disable the check before sending a request, and --light.serveStale on the server side. Then providing a range is not necessary.

I'm open to other suggestions. Or do you think generally too niche a use-case and doesn't warrant a flag?

[fjl]

I think it would be simpler to have a boolean flag, like @s1na says in his last comment.

[fjl]

This is pretty old now, and LES hasn't been operational for quite a while. Should we close?

[s1na]

I will close and open a new one after post-merge LES arrives and when I need this again.