Temper initial eagerness when requesting transactions

[crocodile-dentist]

Recent back to back node releases exposed a weakness in tx-submission logic which imposes a minor but observable increase on network load. It is not a bug per se, since no invalid transactions are disseminated by any nodes, but instead it could be classified as quality of implementation issue. This manifests itself as some nodes repeatedly providing theirs' transactions, on requests by the inbound/server peer, and then disconnecting. Based on initial analysis, this does not appear to be an intended adverserial behavior, but merely a consequence of current design.

The issue concerns a corner case where there are a mixture of interacting nodes and some of which are unable to cross a hard fork boundary. When these legacy nodes connect to a node which is in fact across the boundary, a full set of miniprotocols are established, and a race between tx-submission and chainsync occurs. The legacy node may respond to a request for transactions before it learns from chainsync that it does not support that peer's block versions, and it will disconnect. After a short timeout expires, it will reconnect and repeat this cycle. Since chainsync miniprotocol is pipelined, it would be onerous to try to somehow synchronize tx-submission with it. Instead, a timeout could be established which would prevent the inbound/server peer from submitting its initial request to the client for a brief while, and long enough for the client to disconnect for aforementioned reason, or some other. This approach has the added benefit of making a client expend some resources when making the initial connection - in a healthy network good connections are long lived and so this initial timeout period has no foreseen detrimental effects on network performance.