Deleting an anchor in the "conflict" state can also delete the namespace from another parent

[yiqigao217]

This could be a race condition when two parents both create a subnamespace anchor with the same name simultaneously. The webhook could be bypassed if the second anchor is created before the forest is updated.

Test and see what would happen if we delete the bad anchor in one of the parent. The good anchor is the one in the namespace that the subnamespace points to as the parent.

[yiqigao217]

/assign @yiqigao217
cc @adrianludwin

[yiqigao217]

FTR the current behavior is that the subnamespace of the good anchor will also be deleted when we try to delete the bad anchor, which is very dangerous. The change in #799 will prevent this.

[adrianludwin]

Note that this bug, while scary, is doubly-unlikely to occur in HNC v0.4:

• The validation controller will attempt to prevent you from creating a bad anchor. A bad anchor can only be created if the webhook is disabled, or in extremely rare circumstances if there's a race condition.

• In HNC v0.4, you cannot delete any subnamespace unless allowCascadingDelete is set to true in that subnamespace (this restriction is relaxed in v0.5). Since this field should very rarely be set, it will typically not be possible for the owner of a bad anchor to delete someone else's namespace.

Note that this is a good validation of our defence-in-depth strategy to make sure it's very difficult to delete subnamespaces.