xds: Assert XdsNR's cluster ref counting is consistent

[ejona86]

It is much harder to debug refcounting problems when we ignore impossible situations. So make such impossible cases complain loudly so the bug is obvious.

[larry-safran]

Since this is being added to the end of the queue, it is possible that another update has come in restoring use of the cluster before this runs, in which case doing nothing is appropriate.

[ejona86]

Because there's a refcount and the clusterRefs map, the threading simply breaks down if the refcount goes from 0 → 1. That's why we already don't use an atomic increment, and instead use compareAndSet to increase the value:

grpc-java/xds/src/main/java/io/grpc/xds/XdsNameResolver.java

Lines 523 to 528 in ca4819a

	do {
	count = refCount.get();
	if (count == 0) {
	return false;
	}
	} while (!refCount.compareAndSet(count, count + 1));

1 → 0 is a one-way state transition, and the only option is to throw away the object.

In my debugging, I was worried that there could have been a bug in the reference counting that left things in a corrupted state. I don't think there is any such bug, but I'd much rather see an exception than silent state corruption.