fix kube-ovn-cni crash for newly added nodes , due to old legacy event

[changluyi]

Pull Request

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

What type of this PR

Examples of user facing changes:

问题现象：

集中式网关当只有唯一一个节点的时候，将这个节点从集群中删除，然后再加回来时，偶发kube-ovn-cni 起不来

问题原因：

是由于handleDeleteNode 一直没有删除成功，导致报错

 failed to delete policy route for centralized subnet ovn-default, subnet ovn-default gws are not ready

失败后会event 一直放进deleteNodeQueue。

但是当下一次同名节点成功加入后，由于删除的事件还在deleteNodeQueue 中，仍然会走到 handleDeleteNode 所以导致了某些节点相关的db 比如lsp，portgroup被清理了。

问题解决办法：

目前没想到比较好的方法，
方法1：
如果从deleteNodeQueue 中强制清理掉删除的event，handleDeleteNode 就没完全成功，导致某些规则没有清理的话，会不会导致下一次添加节点出问题。

我这边说的不一定是这个集中式网关的例子，handleDeleteNode return err的地方也不少，如果要强制从队列清理掉删除event的话，那估计得检查，在handleDeleteNode任意一个点如果return err会不会导致下一次node 加入失败。

方法2：
该pr 使用的，如果addNode的时候 发现有删除event在队列中，那就报警，让用户自己评估。

Which issue(s) this PR fixes

Fixes #(issue-number)

[oilbeater]

handleDeleteNode 的时候检查一下如果 cache 里 node 还存在就返回呢，这时候以及不需要再做 delete 处理了

[changluyi]

handleDeleteNode 的时候检查一下如果 cache 里 node 还存在就返回呢，这时候以及不需要再做 delete 处理了

可以，return的时候带上个warning log，如果由于delete没执行完，某些垃圾没被清理导致下次加入失败的话，那只能用户自己通过kube-ovn-controller.log自己排了

不过本来这种case就比较少见

[oilbeater]

那还是优先检查一下存在在处理吧，和 pod 的处理保持一致

[changluyi]

那还是优先检查一下存在在处理吧，和 pod 的处理保持一致

好的，已修复。

[oilbeater]

直接 lister.Get 看能不能找到就可以了，不需要单独记录

[changluyi]

直接 lister.Get 看能不能找到就可以了，不需要单独记录

已修，不过handledeleteNode的时候还是需要个map存放obj。