If a node can be reached by, e.g., 100 nodes, then it will be added to grays 100 times (and refs will be called 100 times for this node). This PR avoids this by pre-marking a node as non-white right after it's added to grays.

My understanding from the code is we can/should avoid such duplications in grays (and duplicated refs(node) calls within a Tricolor call).

1. Tricolor is single-thread GC, and only called once by DB.getMarked
   

   containerd/core/metadata/db.go

   Line 516 in 4cfeb7b

   reachable, err := gc.Tricolor(nodes, refs)

2. getMarked is only called once by DB.GarbageCollect which holds a write lock to DB:

   containerd/core/metadata/db.go

   Lines 372 to 376 in 4cfeb7b

   	m.wlock.Lock()
   	t1 := time.Now()
   	c := startGCContext(ctx, m.collectors)
   	marked, err := m.getMarked(ctx, c) // Pass in gc context

3. So there should be no concurrent writes during a Tricolor call, and repeated refs(node) calls will return the same results and thus should be avoided.

The added benchmark on my macbook:

# before the change
$ go test -bench=. -benchmem -count 5 ./pkg/gc/...
BenchmarkTricolor-8        40724             26680 ns/op           75641 B/op        134 allocs/op
BenchmarkTricolor-8        45002             26666 ns/op           75646 B/op        134 allocs/op
BenchmarkTricolor-8        44790             26622 ns/op           75636 B/op        134 allocs/op
BenchmarkTricolor-8        45115             26654 ns/op           75639 B/op        134 allocs/op
BenchmarkTricolor-8        44782             26682 ns/op           75643 B/op        134 allocs/op
# after the change
$ go test -bench=. -benchmem -count 5 ./pkg/gc/...
BenchmarkTricolor-8        48979             22379 ns/op           71538 B/op        133 allocs/op
BenchmarkTricolor-8        53335             22484 ns/op           71541 B/op        133 allocs/op
BenchmarkTricolor-8        53569             22260 ns/op           71550 B/op        133 allocs/op
BenchmarkTricolor-8        53278             22312 ns/op           71545 B/op        133 allocs/op
BenchmarkTricolor-8        53372             22421 ns/op           71547 B/op        133 allocs/op

By creating a graph where A -> [X1, X100] -> D, it shows the GC latency has a ~16% improvement (22260/26622=84%). Memory also has ~6% reduction (71550/75636=94%). (the actual improvement will depend on the cost of calling refs and number of duplicated nodes).

Appreciate any feedback/concern, thanks!