[ upstream commit 592ff13ae8f93f18fe78180d91f5b4cb4be02562 ]

**TL;DR.** We only need one of an XFRM IN policy or an XFRM IN state to
match each packet. This commit removes one superfluous XFRM IN policy
and enables some additional simplification as a result.

What XFRM IN policy we install currently depends of whether we are
running in tunneling mode and with or without endpoint routes:

In tunneling mode:
    XFRM IN policy matching on mark 0x200/0xf00 (for proxy)
    XFRM IN policy matching on mark 0xd00/0xf00 (for decrypt.)

In native routing mode with endpoint routes:
    XFRM IN policy matching on mark 0x200/0xf00 (for proxy)

In all cases, we also have:
    XFRM IN state matching on mark 0xd00/0xf00 (for decrypt.)

The two policies in tunneling mode were introduced by a9f18f36
("datapath/linux/ipsec: Insert additional In rule when tunneling"). The
additional case for endpoint routes was introduced by 3ffe49e1 ("ipsec:
Fix L7 with endpoint routes"). Now, I got to wonder how 3ffe49e1 even
worked as it was missing an XFRM IN policy for 0xd00 which a9f18f36
suggested was necessary.

After some local testing, it turns out that the two XFRM IN policies for
tunneling mode are not required. All we need is to have either (1) an
XFRM IN policy or (2) an XFRM IN state matching the packets. The XFRM
state is needed if we want to decrypt packets; the XFRM policy is needed
to not drop packets that don't match an XFRM state.

Given we always have an XFRM IN state for packets coming with the
decryption mark, we don't need an XFRM IN policy for that. We only need
an XFRM IN policy for packets coming with the proxy mark because we
don't have a state for those, rightly so as we don't want to decrypt
them.

This commit therefore removes the XFRM IN policy for decryption. It also
removes any dependency on particular options: we will always install the
XFRM IN policy for the proxy. It doesn't hurt to have that policy even
if not required (e.g., in native routing mode without endpoint routes).

**How was this tested?**

This change was tested with our Jenkins IPsec tests (including the
quarantined one for VXLAN), as well as with GKE and EKS clusters of 3
nodes. In all cases, the connectivity tests were executed and L7
policies were thus covered.

Signed-off-by: Paul Chaignon <paul@cilium.io>
Signed-off-by: Sebastian Wicki <sebastian@isovalent.com>