network: remove GossipNode.BroadcastArray

[cce]

Summary

In #1966 the methods BroadcastArray and RelayArray were added to the GossipNode interface. (The idea was to break up long messages like proposals into a sequence of smaller messages, to allow canceling a proposal while it was still being sent, as soon as a better one was observed.) However they were never used, and have no callers. They require every (tag, message) pair, to be wrapped in two single-element []protocol.Tag and [][]byte slices. This PR attempts to see if it is straightforward (and more performant) to go back to single-message sending, without the slice wrappers.

Review recommended with whitespace hidden.

Test Plan

Updated TestWebsocketNetworkCancel and TestPreparePeerData for missing BroadcastArray. Existing unit & e2e test should ensure that networking is still working with single messages.

[codecov]

Codecov Report

Attention: Patch coverage is 95.65217% with 2 lines in your changes missing coverage. Please review.

Project coverage is 51.66%. Comparing base (272ec02) to head (9db0a1c).
Report is 3 commits behind head on master.

Files with missing lines	Patch %	Lines
network/wsNetwork.go	90.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6281      +/-   ##
==========================================
+ Coverage   51.63%   51.66%   +0.02%     
==========================================
  Files         647      647              
  Lines       86907    86874      -33     
==========================================
+ Hits        44876    44883       +7     
+ Misses      39161    39126      -35     
+ Partials     2870     2865       -5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gmalouf]

We still have an idea on our board to split up the block proposal - does this make that harder, or just revisit when we get to it?

[jannotti]

We still have an idea on our board to split up the block proposal - does this make that harder, or just revisit when we get to it?

I think if we want to go back, we could retain the single broadcast method, but implement it with a sync.Pool for the singleton slices.

Though it makes me wonder: Are we sure this was even allocating? I think Go can allocate small slices on the stack if they're just fed into another function and don't escape. I might be imagining that.

[algorandskiy]

Though it makes me wonder: Are we sure this was even allocating? I think Go can allocate small slices on the stack if they're just fed into another function and don't escape. I might be imagining that.

It does escape at least in Broadcast():

network/wsNetwork.go:364:19: make([][]byte, 1) escapes to heap
network/wsNetwork.go:366:18: make([]protocol.Tag, 1) escapes to heap

[cce]

I was thinking if we want to split up the block proposal (and support canceling mid-stream), we could add special handling in readLoop/writeLoop for handling large PP-tagged messages. When @algorandskiy added proposal compression, he added special handing for PP tag messages to the readLoop (to decompress them) and we have other special handling of tags in readLoop and writeLoop as well (for large message caching and other things).

IMO, to implement proposal splitting/canceling, it could be more clear to have a single large message with a single PP tag show up to be sent to the writeLoop, rather than a sequence of split-up messages of different tag types that were split up by the sender or inside of agreement.