Previously, Cilium would only respond to ARP requests for the gateway IP
address. However, in rare cases Cilium could change the gateway IP
address upon restart, and this could cause connectivity disruption for
existing containers. For instance, if a container has a link scope route
for the old gateway G1, and the ARP entry times out, then Cilium is
restarted, the new Cilium will install a BPF program that responds to
requests for a new gateway G2. However, the endpoint does not have a
link scope route for G2. It will ARP for G1, but the new BPF program
will only respond to ARP requests for G2. Cilium will forward the ARP
request to the Linux stack, but there's no G1 IP configured so Linux
does not respond. As a result, the endpoint is stuck without the ability
to send any traffic.

We really only want to force the endpoint to send traffic through the
veth device, and after that point we will route via L3 to the
appropriate destination. So, if we respond to ARP requests for all IPs
with the mac of the other side of the veth pair, then the endpoint will
always see an ARP response for an IP, and it will send the traffic out
the veth pair, after which point Cilium can route the traffic.

This fixes an issue during Cilium restart where endpoints could lose
connectivity and would not get back into a good state without being
restarted.

Signed-off-by: Joe Stringer <joe@covalent.io>