Fix data races in TestLDBStoreCollectGarbage

[janos]

This PR addresses race condition described in #1118 and a similar one in gc tests.

This change solves data races, but it does not solve failing tests when go test tool is called with -race. Tests are failing with not all expected chunks deleted by the garbage collection. If tests are run without the -race flag, they are passing as usual. Currently, the flaky test is disabled.

We agreed on the standup not to dedicate more time to this failing tests, as regular tests are passing and we are working on a different gc implementation.

[frncmx]

I think we could use just a read lock, couldn't we?

[frncmx]

@janos I'm a little bit confused about the status of this PR, could you help me out?

The test does not fix TestLDBStoreCollectGarbage as stated in the commit and above you say we don't want to spend more time on this issue.

Shall we just close this with a no fix?

[correction: fixes the data race but causes the test to fail for other reasons.]

[frncmx]

As discussed, on stand-up I'm trying to figure what to do with this.

Problem:

$ go test -race -count 1 -run TestLDBStoreCollectGarbage github.com/ethereum/go-ethereum/swarm/storage -loglevel 0
--- FAIL: TestLDBStoreCollectGarbage (59.98s)
    --- FAIL: TestLDBStoreCollectGarbage/B/50/200 (1.25s)
        ldbstore_test.go:559: expected surplus chunk 150 to be missing, but got no error
    --- FAIL: TestLDBStoreCollectGarbage/B/100/400 (3.15s)
        ldbstore_test.go:559: expected surplus chunk 300 to be missing, but got no error
FAIL
FAIL	github.com/ethereum/go-ethereum/swarm/storage	62.153s

Context:

• LDB is going to be replaced by the new localstore implementation => limit time and effort
• tests are failing because the pressure caused by -race

1st (ugly,cheap) idea: skip the 2 failing test cases when -race provided.
Learning:

• there is no testing.Race() as there is testing.Verbose()
• -race is a build flag to alternate between norace.go and race.go
• there is a const called race.Enabled however that cannot be accessed because race is an internal package
• nice, because Go really protects me from choosing the ugly solution

2nd idea: just drop the new locks and the 2 debug log lines

• that also solves the race
• still, the two test cases fail with -race
  => Failure is totally unrelated to the change.

3rd idea: debug
results: seemingly we must trigger another GC round, simplest way to add before the failing for loop ldb.collectGarbage()

[frncmx]

Calling ldb.collectGarbage() directly in test did not solve the flakiness as expected. The above mentioned test might still fail when run with -race. That blocks #741 => I vote to skip the test until we fix waitGC() (#1151) or ldb gets replaced by the new localstore.

[janos]

@frncmx I agree.

[frncmx]

opened upstream ethereum/go-ethereum#18512