[ upstream commit 31a5ff1620e7f3b222af0c884351e161e04539cd ]

[ Backporter's notes: the tests had to be adapted because the signature
  of `IPIdentityCache.Upsert` has been changed in
  c5d4b7efc978ff4ae99f23bee3078f885a94892f in v1.10, which was not
  backported to v1.9. ]

These tests answer the following questions:

* What happens if we receive an add/ update event from k8s with a pod
  that is using the same IP address of an
  already-gone-pod-but-delete-event-not-received?
* What happens if we receive an delete of an already gone pod after we
  have received an add/ update from a new pod using that same IP
  address?

What these tests confirm is that Kubernetes events that are out-of-order
are handled as they're received. Meaning the ipcache doesn't have any
special logic to handle for example whether an ipcache delete for a pod
X with IP A is the same pod X (by namespace & name) which previously
inserted an ipcache entry.

Suggested-by: André Martins <andre@cilium.io>
Signed-off-by: Chris Tarazi <chris@isovalent.com>
Signed-off-by: Nicolas Busseneau <nicolas@isovalent.com>