fix: handle pod deletion in kubearmor controller

[Aryan-sharma11]

Purpose of PR?:

Fixes #1935

Does this PR introduce a breaking change?
No

Changes included
1) Handle pod restarts

• Currently In case of AppArmor enforcer we delete all existing pods in the cluster to add AppArmor security annotations. Since this can cause a downtime in application the new approach implemented in this PR is that, we will be updating the deployments with annotation "kubearmor.kubernetes.io/restartedAt" to trigger a rolling restart for all the pods.

2) NodeWatcher

• Currently we have a node watcher implemented in controller which keeps track of AppArmor nodes present on the cluster, now with this PR we will be keeping track of whether kubearmor daemonset is present on the node or not and if present is it in running state or not, so will be adding the AppArmor annotation on the pods on which kubearmor is in running state so to avoid annotating the pods on the nodes which doesn't have kubearmor.

3) Pod Mutation

• Currently we have pod webhook mutation implemented for pod create and update events, since the event is created before the pod is scheduled on a node, we were missing out on node info, with this PR we will be watching over pod/bindings event since they are generated after the pod is scheduled and before the pod is started so the bindings contains the target node info.
  This will help us in optimising our annotation handling for hybrid clusters (AppArmor + BPFLSM enforcer) therefore improving overall controller performance
• we will still be watching for pod create events in webhook mutation for the cases when the pod already has nodename at the time of creation as it skips the scheduling step.

ref