les: add checkpoint challenge for light client

[rjl493456442]

Replace #20125

[rjl493456442]

This PR is blocked by #20692

[rjl493456442]

I should rebase it and @zsfelfoldi Please take a look.

[holiman]

Discussion: instead of matching wildcard responses, use the request-id / response id for matching.

[rjl493456442]

Simplify it by checking the reqid

[rjl493456442]

@zsfelfoldi Think about this PR for a while, now I am inclined to close this PR.

The main purpose of the checkpoint challenge is we want to ensure the remote peer is in the same chain as us before we run the sync protocol. It's super useful for ETH protocol because we sync from the local head anyway and it will take a very long time to finish the sync(usually).

However, for LES, the checkpoint challenge seems unnecessary. Light client syncs from the checkpoint anyway and the checkpoint is verified in two ways:

• It's the hardcoded checkpoint, trust it anyway, no verification
• It's the signed checkpoint by Geth devs, verify the signature

And after the verification, we will firstly sync the checkpoint and then the remaining headers.
So it means before the real sync, we already ensure the remote peer is on the same side as us.

It might be useful in the future if we implement the flexible light sync that can start in any specified CHT. In this case, users want the legacy headers but still want to sync the correct chain. So the checkpoint challenge can help.
But really not sure whether it's worthwhile to add this complexity.