Make INV broadcast interval and rate command-line options with ms resolution

Summary

[tx relay] Make INV broadcast interval and rate command-line options with ms resolution, default 500 ms and 7tx/MB/sec

1. The interval between inv messages for new transactions has important implications for UX and for scalability.

The inv messages for transactions are responsible for the vast majority of a node's total network traffic, since inv messages are sent per peer regardless of whether that peer needs the transaction or not. If a node is sending one inv per tx per peer, and the node has 50 peers, that results in about 120 bytes/tx/peer * 50 peers = 6000 bytes of network traffic per transaction, or roughly 6x as much traffic as is required for receiving and sending the transaction itself (assuming a typical 500 byte transaction). In this scenario, about 2/3 of the traffic is actually protocol overhead -- mostly TCP/IP overhead, but also bitcoin p2p protocol overhead. This overhead can be mitigated with batching. Using IPv4, inv messages take up about 80 + 40n bytes per message, where n is the number of transaction hashes being sent. This means that batching behavior can reduce the average traffic per peer per tx from around 120 bytes (for a batch size of 1) to around 44 bytes (for a batch size of 10). The way to achieve large batch sizes is to have a delay before sending each tx inv to allow extra txs to be ready in each transmission. A batch size of 10 can be achieved with 20 tx/sec and an average delay of 2 sec, for example.

However, delays like this will significantly slow down transaction propagation, and will adversely affect UX. A delay of 2 seconds per connection with 20 connections means that a node will broadcast an inv to one peer every 100 ms on average. This delay, coupled with the natural network ping times of ~100 ms, and the 1.5 RTT communication needed to send a tx, means that the number of nodes who have a transaction will double roughly every (100 ms + 150 ms) = 250 ms if all network nodes used a 2 second delay with 20 peers. If the network is comprised of 8192 nodes, it would take around 3.25 seconds for a transaction to propagate through the full netowrk. This worsens BCH's UX by making transactions feel slower in 0-conf mode, and gives a much larger time window for double-spends than is desirable.

This commit makes the interval between inv announcements per connection a command-line configurable option, set by the -txbroadcastinterval option. This commit also gives this value millisecond resolution, and sets the default value to 500 ms for incoming connections (and half that for outgoing) instead of 5 seconds incoming (2 sec outgoing).

2. The rate at which new inv messages are broadcast has important implications for scalability.

In order to mitigate spam attacks, the node will limit the rate at which new transaction invs are broadcast to each peer. The default is to limit this to 7 tx/sec per MB of excessive block size. That is, with a 32 MB blocksize limit, no more than 224 tx invs are allowed to be broadcast each second. This commit makes this broadcast rate limit configurable, set by the -txbroadcastrate command-line option.

Test plan

ninja check-functional

Merge plan

This needs to be manually squashed down to two commits (one for matricz, one for me).

Cross-references

See also !143 (closed) and !289 (closed) for similar MRs.

Closes !143 (closed) and !289 (closed)

Depends on !839 (merged)