Don't enqueue VPC update when DeletionTimestamp is zero

[sirkrypt0]

We change the check to not enqueue a VPC update when the DeletionTimestamp is zero. Previously, the VPC update would basically always be enqueued, as the DeletionTimestamp would be zero until it was scheduled for deletion. This lead to a huge amount of enqueued VPC updates and therefore a lot of Kubernetes API requests and load on the API.

The logical not was removed in #3107 which therefore introduced this bug.

• Make sure you have followed Kube-OVN Code Style.

What type of this PR

Bug Fix

Which issue(s) this PR fixes:

Fixes #3301

WHAT

🤖 Generated by Copilot at 01fc78b

Fix Vpc deletion bug by enqueuing update events when Vpc has deletion timestamp. Modify pkg/controller/vpc.go to implement this logic.

🤖 Generated by Copilot at 01fc78b

Vpc deletion
Enqueue update event now
Fixes autumn bug

HOW

🤖 Generated by Copilot at 01fc78b

• Fix issue security: update base ubuntu image #1144 by enqueuing Vpc update events when the Vpc has a deletion timestamp (link)

[bobz965]

How about just removing the !newVpc.DeletionTimestamp.IsZero(), I think the vpc handleUpdate has nothing to do with the delete logic. all the clear logic should in the handleDelVpc

[sirkrypt0]

Looking around, the code contains the same pattern in multiple places, like

kube-ovn/pkg/controller/qos_policy.go

Lines 55 to 59 in 60ef1ad

	if !newQos.DeletionTimestamp.IsZero() {
	klog.V(3).Infof("enqueue update to clean qos %s", key)
	c.updateQoSPolicyQueue.Add(key)
	return
	}

kube-ovn/pkg/controller/subnet.go

Lines 70 to 73 in 60ef1ad

	if !newSubnet.DeletionTimestamp.IsZero() && usingIPs == 0 || (usingIPs == 1 && u2oInterconnIP != "") {
	c.addOrUpdateSubnetQueue.Add(key)
	return
	}

So there might be a reason for why this check exists? Although I currently tend to agree and don't really see a reason for why you'd want to enqueue an update, when the DeletionTimestamp has been set, i.e. the VPC is scheduled for deletion at some point later in time.
Also, I didn't find any logic in handleAddOrUpdateVpc which would rely on the DeletionTimestamp being set, so the other checks should cover any cases where some important properties have been changed, such that anything in the OVN should be adjusted.

[oilbeater]

This pattern is aimed to prevent some race condition but I cannot recall the specific scenario. Maybe the controller receive an update event then a deletion event, but it would process the deletion first then the update and lead to undesired garbage so we add a check before doing update. I think we can just keep the code like this as it can resolve this issue.