cmd/devp2p: add eth/66 protocol test suite

[fjl]

After #22241 is merged, we should extend the protocol test suite to cover the new
message types in eth/66. What needs to be done:

• Rename existing tests to add 65 in name
• Duplicate all existing tests with 66 name and change messages to use eth/66 request ID
• Add checks that the request ID of responses match the requests.
• Add new test that sends two concurrent requests.

Since we now have eth message definitions in package eth/protocols/eth, we might be
able to remove the message type definitions in package ethtest and use the 'real' message
types instead.

[renaynay]

@fjl re:

Add new test that sends two concurrent requests.

can I just send two simultaneous GetBlockHeaders requests and make sure both the request ID and the headers are valid?

[fjl]

Yeah, that's kind of the idea. Basically, the peer needs to be able to deal with concurrent requests in some way.

[fjl]

Some follow-up ideas:

• add test that checks announcement of block hash
• add test that checks announcement of tx hash
• add test that announces existing block in chain (should not propagate)
• add test that announces existing tx in chain (should not propagate)

[fjl]

I checked the results on hive and it looks like the 66 tests continue even if the remote node does not support 66.

[fjl]

one more idea: test the behavior of eth/65 where a peer requests 2000 tx, but only 1000 are sent (because of response limit). if some txs are missing on the remote node, then the list should be truncated in a certain way.

[renaynay]

I checked the results on hive and it looks like the 66 tests continue even if the remote node does not support 66.

Okay, will add a check for highest protocol supported by node to proceed with 66 tests.

[renaynay]

Some follow-up ideas:

• add test that checks announcement of block hash
• add test that checks announcement of tx hash

for block hash -- doesn't TestBroadcast cover this?
same for tx hash - there's already a test for this, unless I'm not understanding correctly.

[fjl]

doesn't TestBroadcast cover this?

There are two ways to announce a block: with NewBlock, sending the complete block; and with NewBlockHashes, sending only the block hash. In the latter case, the node should request the full block a couple seconds later.

[renaynay]

doesn't TestBroadcast cover this?

There are two ways to announce a block: with NewBlock, sending the complete block; and with NewBlockHashes, sending only the block hash. In the latter case, the node should request the full block a couple seconds later.

Hmm, looks like after receiving the NewBlockHashes announcement, the node requests block headers rather than the full block.

[holiman]

Can this be closed now?

[renaynay]

It's kind of an ongoing effort, but I'd say the base is in place so likely yes.