GossipSub: improve flood publish

[Menduist]

Flood publish:
✅ faster propagation of messages
✅ better sybil resistance (the first hop is the most fragile one)
😢 bandwidth usage (scales linearly with number of subbed connected peers)
😢 privacy (when you send a message out of your mesh, you reveal that you are the source)

The bandwidth usage will soon become a bottleneck in ethereum, and we need to find better solutions. Some leads:

• Limit the number of peers we flood publish to (reuse gossipFactor?)
• Rely on flooding IHAVE instead of the full message?
• ?

Will also need adjustments at the specs level

[arnetheduck]

• stagger sending so that some peers receive the (full) message earlier

[Menduist]

Sure, whatever we end up doing for #850 will also apply to flood publishing

[Nashatyrev]

If the parallel sending limiting (same as 'stagger sending') works well, then flood publish shouldn't be the issue: mesh peers would receive messages from publisher with approximately same timings as without floodPublish. A number of nodes (non-mesh peers of the publisher) would just potentially receive +1 duplicate

[Menduist]

The performance part has been addressed in #911
The privacy part is a harder task to achieve

[diegomrsantos]

Flood publishing has been addressed as described in the comment above.

Other improvements related to bandwidth and latency were addressed in:

• GossipSub: IDontWant #934
• Send priority with queue fix #1051
• feat: add max number of elements to non-prio queue #1077
• feat: behaviour penalty when non-priority queue reaches maxNumElementsInNonPriorityQueue #1083 (waiting review)

Can we consider this issue solved? @arnetheduck @kaiserd