Merge remote-tracking branch 'origin/testing'

Xin Long says:

==================
Now ipip and ipv6 tunnels processing is supported by xfrm4/6_tunnel,
but not in vti and xfrmi. This feature is needed by processing those
uncompressed small fragments and packets when using comp protocol.
It means vti and xfrmi won't be able to accept small fragments or
packets when using comp protocol, which is not expected.

xfrm4/6_tunnel eventually calls xfrm_input() to process ipip and ipv6
tunnels with an ipip/ipv6-proto state (a child state of comp-proto
state), and vti and xfrmi should do the same.

The extra things for vti to do is:

  - vti_input() should be called before xfrm_input() to set
    XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip4/6 = tunnel. [A]

  - vti_rcv_cb() should be called after xfrm_input() to update
    the skb->dev. [B]

And the extra things for xfrmi to do is:

   - The ipip/ipv6-proto state should be assigned if_id from its
     parent's state. [C]

   - xfrmi_rcv_cb() should be called after xfrm_input() to update
     the skb->dev. [D]

Patch 4-7 does the things in [A].

To implement [B] and [D], patch 1-3 is to build a callback function
for xfrm4/6_tunnel, which can be called after xfrm_input(), similar
to xfrm4/6_protocol's .cb_handler. vti and xfrmi only needs to give
their own callback function in patch 4-7 and 9-10, which already
exists: vti_rcv_cb() and xfrmi_rcv_cb().

Patch 8 is to do the thing in [C] by assigning child tunnel's if_id
from its parent tunnel.

With the whole patch series, the segments or packets with any size
can work with ipsec comp proto on vti and xfrmi.

v1->v2:
  - See Patch 2-3.
v2->v3:
  - See Patch 2-3, 4, 6, 9-10.
==================

Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>