Process inv with mixed item types

[teor2345]

Work In Progress

• newer: https://github.com/teor2345/zebra/tree/split-merged-inv
• older: https://github.com/teor2345/zebra/tree/multi-block-inv

Is your feature request related to a problem?

Some of my mainnet and testnet Zebra instances occasionally log messages like:

Feb 18 07:47:55.715 WARN {zebrad="12cb8492" net="Main"}:sync: zebrad::components::sync: error downloading and verifying block e=SharedPeerError(WrongMessage("inv with mixed item types"))

Describe the solution you'd like

Process inventory (inv) messages with mixed item types by splitting them into an internal Zebra Response for each type of item:

• split messages in the peer_rx stream in Handshake, before the inventory collector runs on the stream
• split Inv messages by InventoryHash type
• split small multi-block Inv messages into a series of single block messages

Cleanup the handshake code (this should be a separate PR):

• move the large peer_rx closures into separate functions
• move connection wrapper closures into functions
• apply all connection wrappers in handshake, and move them to that file
  • make a comment in connection explaining that Handshake setup also changes connection messages

This will be easier when we upgrade to the latest tower and tokio (#2200), because they implement more trait bounds like Sync and Send.

Describe alternatives you've considered

1. Continue to ignore inv with mixed item types, and continue logging warnings
2. Log an info-level message instead of a warning
3. Add more debugging to work out what the item types actually are

Additional context

I don't know if we need these messages for normal operation - we might be missing out on some gossiped blocks or transactions, or we might be missing out on some responses that were merged into the same inv message.

This is a low priority, until it actually affects Zebra, or the messages become much more frequent.

[teor2345]

Obsoleted by #2156 - if we miss any inv items, the notfound response will stop us trying that peer again.