payload: don't adjust offsets of autogenerated dependency expressions

payload: don't adjust offsets of autogenerated dependency expressions

Pablo says:
  user reports that this is broken:
  nft --debug=netlink add rule bridge filter forward vlan id 100 vlan id set 200
[..]
    [ payload load 2b @ link header + 14 => reg 1 ]
[..]
    [ payload load 2b @ link header + 28 => reg 1 ]
    [ bitwise reg 1 = ( reg 1 & 0x000000f0 ) ^ 0x0000c800 ]
    [ payload write reg 1 => 2b @ link header + 14 csum_type 0 csum_off 0 csum_flags 0x0 ]

    offset says 28, it is assuming q-in-q, in this case it is mangling the
    existing header.

The problem here is that 'vlan id set 200' needs a read-modify-write
cycle because 'vlan id set' has to preserve bits located in the same byte area
as the vlan id.

The first 'payload load' at offset 14 is generated via 'vlan id 100',
this part is ok.

The second 'payload load' at offset 28 is the bogus one.
Its added as a dependency, but then adjusted because nft evaluation
considers this identical to 'vlan id 1 vlan id '2, where nft assumes
q-in-q.

To fix this, skip offset adjustments for raw expressions and mark the
dependency-generated payload instruction as such.

This is fine because raw payload operations assume that user specifies
base/offset/length manually.

Also add a test case for this.

Reported-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>