If an object with a given uid is already in the garbage collector uid map, a child object created with an ownerReference pointing to that uid is not treated as having a non-existent parent, even if:

1. the ownerReference refers to a cluster-scoped kind and no cluster-scoped kind with that name exists
2. the child is namespaced, and the ownerReference refers to a namespaced kind and no namespace-scoped kind with that name exists in the same namespace
3. the child is cluster-scoped, and the ownerReference refers to a namespaced kind (since the namespace of the parent is ambiguous, it should be treated as not existing)

Original description follows

Forked from #63386 (comment).

Garbage collector should work for three cases: (a) cluster-scoped owner with namespaced dependents, (b) namespaced owner and namespaced dependents that are in the same namespace, and (c) cluster-scoped owner with cluster-scoped dependents.

Garbage collector should NOT work for the other two cases: (c) namespaced owner with cluster-scoped dependents. (d) owner and dependents that are in different namespaces. Today, GC sometimes work in these two cases. It's a bug for two reasons:

• This weakens our security guarantees. Users might exploit this bug to grant other users delete permissions.
• Users might rely on the unsupported behavior.

We can add extra checks in the GC controller to make it never work for case (c) and (d).

cc @lavalamp @liggitt @deads2k