The code to handle EGW reply traffic lives in the nodeport ingress path,
after a packet has been RevSNATed. In contrast to the outbound path, it
doesn't consider whether the packet's source is an in-cluster entity.

This becomes problematic when the EGW policy specifies a broad-range
`destinationCIDR`, such as 0.0.0.0/0, and accidentally matches in-cluster
service traffic. More precisely:
* a client pod matches an EGW policy of the form
  "from $client_pod to 0.0.0.0/0, exit via gateway nodeB"
* client_pod accesses a nodeport service on gateway nodeB, where the
  request is DNATed to a remote backend, and SNATed to nodeB's IP.
* once the backend's reply reaches nodeB, it is revSNATed to client_pod.
  At this point the packet matches the EGW policy entry, and is thus
  redirected into the overlay network and forwarded to client_pod.
* As the RevDNAT step has been skipped, client_pod rejects this packet from
  an unknown source.

Fix this by applying the RevDNAT logic *prior* to looking for EGW policy
matches. Double-checking whether the packet's origin is an in-cluster
entity might still make sense, but no longer strictly necessary.


From a tcpdump on a kind cluster (with EGW, KPR without SocketLB and
native routing):

```
 # client accesses nodeport 31936 on remote LB node
IP 10.244.1.236.35556 > 172.18.0.2.31936: Flags [S]
 # request is DNATed + SNATed, and forwarded to remote backend
IP 172.18.0.2.35556 > 10.244.3.121.80: Flags [S]
 # backend's reply reaches the LB node
IP 10.244.3.121.80 > 172.18.0.2.35556: Flags [S.]
 # LB node applies revSNAT, adds VXLAN encapsulation and forwards to client
IP 172.18.0.2.54624 > 172.18.0.4.8472: OTV, flags [I] (0x08), overlay 0, instance 6
IP 10.244.3.121.80 > 10.244.1.236.35556: Flags [S.]
 # client's RST to the backend
IP 10.244.1.236.35556 > 10.244.3.121.80: Flags [R]
```

Signed-off-by: Julian Wiedmann <jwi@isovalent.com>