[Proposal] Change how transactions are broadcasted to significantly reduce P2P bandwidth usage 
monerod uses dandelion++ to propagate txs around the network, this happens in 2 stages: stem and fluff. This proposal will only affect txs in the fluff stage.

When monerod receives a fluff tx, it will queue it for broadcasting to every peer except the one that sent it to us first, it doesn't matter if the peer(s) need it or not.

Because monerod sends the whole tx blob this is extremely inefficient, as the majority of the time the peer already has the tx.

## The Proposal

Instead of sending the whole tx-blob just send the hash and allow the peer to request the tx if they need it. This requires 2 new P2P messages:  `TxPoolInv`, `RequestTxPoolTxs` (names not important for now).

Adding support for these P2P messages should be done before changing how txs are broadcasted.

### `TxPoolInv`

This message will contain a list of new tx hashes and will be used when fluffing txs instead of `NewTransactions` which is currently used. 

When a node receives this it will request the txs with `RequestTxPoolTxs` if they are not in the tx-pool.

### `RequestTxPoolTxs`

This message will also contain a list of tx hashes. When a peer receives this message it should look in the _public_ tx pool and respond with as many txs as possible in a `NewTransactions` message.

A peer should not be punished for not responding to a `RequestTxPoolTxs` as the tx(s) could have been dropped from the peers pool.

## How inefficient is the current method?

Using the same technique as was done in the [Erlay paper](https://arxiv.org/abs/1905.10518) we can work out the expected number of wasted broadcasts: 

Each tx is sent _at least_ once along each connection, most of time it's more. If the number of nodes in the Monero network is N then the number of links is 12N as each node by default makes 12 outbound connections, then the number of redundant broadcasts is 12N - N = 11N.

So this means that ~90% of current tx broadcasts are redundant. Although we can't drop the 90% number without introducing a protocol like Erlay, we can redefine what a broadcast is. This would also lay the ground work for potentially adding Erlay in the future although that is not what this proposal is for.

To validate this I ran some tests on a local, fully synced, Monero node (monerod), the node was set to keep 12 outbound connections and 0 inbound.

In 2 hours 30 minutes I collected around 250MBs of data, in which there were 96268 tx broadcasts.

When you send a tx to a peer, if the peer doesn't also send the tx you know you were the first to send that tx to them, if they do send the tx as well you were not the first to send it to them.

So if a tx is sent more than once in a connection I added the amount of times it was sent to the total wasted. In total I got 90562 wasted broadcasts, I didn't take into account re-broadcasts which happen after 5 mins because they don't happen too often.

The total size of the wasted data: 200MB.

With the new method those 90562 wasted broadcasts would be tx hashes, and the 5706 valid broadcasts would require 2 tx hashes which comes to just over 3MB of data.

So I think we could save ~75% of the currently used p2p bandwidth. (250-53)/250 = 0.78. Under heavy load, like seen in the spam waves recently, this percentage should be higher.

## Other benefits

I suspect the current broadcasting method is what lead to nodes getting killed: #9317. 
 