TestGroupKWFPoolDestroyedDropsFromPlacer flakes: placer picks a PoolMissing pool #198

TestGroupKWFPoolDestroyedDropsFromPlacer fails intermittently: the placer puts a diskful replica on the node whose pool was just marked PoolMissing.

--- FAIL: TestGroupKWFPoolDestroyedDropsFromPlacer (8.87s)
    group_k_test.go:473: placer landed diskful replica on node worker-1 with PoolMissing pool lvm-thin ...

It predates #193. Local runs, 56 iterations on each side:

• d2c6112d (before fix(rest): roll a clone or restore back when its parent group is deleted #193): 2 failures
• 5c354a0b (after fix(rest): roll a clone or restore back when its parent group is deleted #193): 4 failures

That is not enough to tell whether the rate changed, but it does show the failure is older than #193.

The test waits for Status.PoolMissing through the direct client (group_k_test.go:435) and then autoplaces right away. My guess is the placer reads storage pools through the manager's cache, which can still hold the pool without PoolMissing. If so, either the test races the informer, or the placer has a real window after a pool goes missing where it still picks it. The second is the Bug 83 case on a real cluster too, so it's worth checking which one it is before making the test wait longer.

To reproduce:

go test -tags=integration ./tests/integration/ -run 'TestGroupKWFPoolDestroyedDropsFromPlacer$' -count=20