les: implement server handler fuzzer

[rjl493456442]

This PR adds the LES fuzzer for fuzzing server handler.

Please keep the two commits from @zsfelfoldi if we decide to merge this PR.

[holiman]

Just curious, would it be possible to abstract away the reqID from the method handler, and have that handled on the outside?
Like, reply.SetReqId(reqID) ?

I'm wondering, because for eth, when we implement eth/66, it would be neat to use a similar handling, but only set the reqId on the response in the cases where the protocol is 66.

[rjl493456442]

Well. Not sure it's necessary. REQID exists in the protocol all the time.

[rjl493456442]

Looks like the fuzzer now works correctly

2021/01/29 10:16:56 workers: 8, corpus: 33 (1h10m ago), crashers: 0, restarts: 1/9818, execs: 6706112 (140/sec), cover: 3073, uptime: 13h16m

[rjl493456442]

@zsfelfoldi I change this to the struct instead of the pointer. Because I think the pointer is unnecessary.

[holiman]

I'm a bit torn. You've rearchitected it so the basic pattern is

1. Unmarshall message.
2. Call message.Serve(backend, foo, bar...).

I'd prefer that it's not based on the actual messages doing the handling but instead

1. Unmarshall the message
2. Lookup the handler based on message id or type
3. hander( msg, backend, foo, bar, ...)

[holiman]

These shouldn't really be needed...?

[zsfelfoldi]

@holiman I need a struct type definition for each message type in order to unmarshall so it just seemed logical to define the handler function over the message type structs. What is the drawback? Would you prefer putting the decoding of the actual request inside the handler functions? (that just seemed like unnecessary duplicated code to me because I want to do the same rlp decodind and decode error handling for each message type)