archival node with excessive rewind behavior

[antiochp]

Related #3552

Looks like archival nodes are exhibiting excessive "rewind" behavior.
Still investigating but working assumption is this is "old" nodes requesting historical blocks (likely V4 nodes pre-HF4).
I think this only occurs if the archival node accepts peer requests from arbitrary nodes (and does not restrict via preferred/allow lists).

This appears unrelated to "archival mode" functionality itself.

...
20210306 07:42:56.459 WARN grin_chain::txhashset::txhashset - rewind_single_block: 1 output_pos entries missing for: 00001ba53238 at 796330
20210306 07:42:56.461 WARN grin_chain::txhashset::txhashset - rewind_single_block: 4 output_pos entries missing for: 000276626e1f at 796329
20210306 07:42:56.462 WARN grin_chain::txhashset::txhashset - rewind_single_block: 1 output_pos entries missing for: 0001b4f8cd33 at 796328
20210306 07:42:56.464 WARN grin_chain::txhashset::txhashset - rewind_single_block: 8 output_pos entries missing for: 00011f98c602 at 796327
20210306 07:42:56.466 WARN grin_chain::txhashset::txhashset - rewind_single_block: 2 output_pos entries missing for: 00005e4a280f at 796326
20210306 07:42:56.468 WARN grin_chain::txhashset::txhashset - rewind_single_block: 5 output_pos entries missing for: 00029273dbd9 at 796325
...

---

The only place I know of that causes rewind like this is when we convert v3 blocks (as stored in the db) to v2 serialization format, due to peer not supporting v3 (hence old legacy peers).
We should ensure that archival nodes filter these requests out effectively. if this is indeed the cause of this behavior.

[antiochp]

These are related -

grin-server.log.7.gz:20210306 01:29:40.132 DEBUG grin_chain::chain - convert_block_v2: 000251721c7d at 781244 (v3 -> v2)

There is no reason we should be attempting to convert a historical block from v3 -> v2 like this.
This is effectively an invalid request from a peer and should be ignored (and peer potentially even banned).