cmd/swarm: speed up tests

[acud]

this PR addresses ongoing efforts to speed up travis in continuation to @fjl's PR #17854
we will continue to work on this in order to improve test run performance.

these minor changes already shaved off around 30s:
github.com/ethereum/go-ethereum/cmd/swarm 163.721s

[fjl]

One thing you could try is to reuse the test cluster across tests.

[acud]

@fjl i think there's a number of things that we might be able to in order to speed things up. also, bringing the test clusters up and down could also be somewhat optimised.
i'm just not sure at the moment on how to imperatively reset the clusters without juggling and introducing ugly hacks.
in the meanwhile i think we can ship this and we'll invest more time into speeding things up

[nonsense]

@justelad if newTestCluster is considerably slower than testutil.NewTestSwarmServer, then please change it also in export_test.go.

[fjl]

But why does the cluster need a reset at all? The tests perform different high-level operations on a standard-ish swarm network. It shouldn't really matter whether that network was just started with no content. If you ran the same test scripts against a swarm instance connected to the main network, they should still work.

[nonsense]

@fjl I agree with you, I would just merge this right away, and then pursue the change where we have a shared cluster among many tests.

[acud]

if newTestCluster is considerably slower than testutil.NewTestSwarmServer, then please change it also in export_test.go.

this involves extending the the testutil.NewTestSwarmServer functionality with newTestCluster funtionality. since the test server provides a much smaller subset of features.

i support the change as long as there's no requirement for a clean database (e.g. - you might want to have a clean address book before each test runs). also there is the question of what happens when you start pumping data of different test runs into the cluster and the cluster will be syncing a lot of messages in regards to syncing and discovery - this might overcloud the benefits of the setup/teardown times and would need to be inspected closely.