Tests: Fix t.Parallel() errors in netdeploy package

[michaeldiamant]

Enables https://github.com/kunwardeep/paralleltest on netdeploy by fixing linter warnings. Incrementally moves the ball towards greater unit test parallelization, which reduces local + CI test durations.

I vetted for flakiness by running:

go test -race -count 10 ./netdeploy/...

Notes:

• The PR does not intend to rework all sequential tests into parallel tests. My objective is to enable already available parallelism throughout go-algorand. And then make a pass through remaining sequential tests to see if/where more parallelism exists.

[codecov]

Codecov Report

Merging #4993 (5055091) into master (a688c23) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4993      +/-   ##
==========================================
- Coverage   53.44%   53.43%   -0.01%     
==========================================
  Files         431      431              
  Lines       54364    54364              
==========================================
- Hits        29056    29052       -4     
- Misses      23053    23059       +6     
+ Partials     2255     2253       -2     

Impacted Files	Coverage Δ
ledger/blockqueue.go	82.25% <0.00%> (-2.69%)	⬇️
catchup/peerSelector.go	98.95% <0.00%> (-1.05%)	⬇️
util/rateLimit.go	81.37% <0.00%> (-0.99%)	⬇️
cmd/tealdbg/debugger.go	71.65% <0.00%> (-0.79%)	⬇️
ledger/testing/randomAccounts.go	56.26% <0.00%> (-0.62%)	⬇️
catchup/service.go	68.70% <0.00%> (-0.24%)	⬇️
network/wsNetwork.go	65.16% <0.00%> (ø)
ledger/acctonline.go	79.16% <0.00%> (+0.52%)	⬆️
ledger/catchpointtracker.go	58.69% <0.00%> (+0.78%)	⬆️
ledger/tracker.go	75.94% <0.00%> (+0.84%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[cce]

it seems only to read config.Consensus, but I guess the fear is someone else may modify config.Consensus?

[jdtzmn]

Is it not mutated on line 108? Assuming it is mutated on line 108, is there supposed to be a cleanup step that's missing?

[cce]

but that's on a copy of the params made on line 95, so it doesn't affect the params in the global map

[jdtzmn]

Ah yes - you're correct. I had forgotten that the values of the map are structs.

[jdtzmn]

I tried using t.Parallel() on these tests and they all passed. Empirically, I've found that tests which read config.Consensus don't have any issues being parallelized when other tests containing Consensus mutations are not parallelized. I've tried looking for a more concrete answer to this online to no avail. @cce do you know any more about how parallel vs. sequential tests are sandboxed? Perhaps they are run one after another?

[jdtzmn]

I can confirm that I am able to add t.Parallel() to these tests locally and that the test cases pass even with -count=40 and above.

[cce]

Yes go test will ensure that if a test doesn't t.Parallel(), it will not be run at the same time as any other test

[jdtzmn]

Changes look good! I went ahead and parallelized the two tests that appear to mutate config.Consensus but do not, as @cce pointed out. I additionally parallelized test files in the netdeploy package that were not caught by the golangci regex.

[algochoi]

Rebased the changes off of master, and it passes the following commands: go test -race -count 10 ./netdeploy/... and golangci-lint run --disable-all -E paralleltest netdeploy/...