Bug 1949171

Description of problem:

given the following entries
tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=10000,dport=80),reply=(src=10.1.1.2,dst=10.1.1.240,sport=80,dport=10000),protoinfo=(state=ESTABLISHED)
tcp,orig=(src=10.1.1.1,dst=192.168.2.100,sport=10000,dport=80),reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10000),protoinfo=(state=ESTABLISHED)

and the replies of a snat'ed connection hit a bare nat rule twice, the resulting
source IP gets translated to 192.168.2.100 (see the attachment).

How reproducible:
Always

Steps to Reproduce:
create two namespaces
- left (iface IP: 10.1.1.1)
- right (iface IP: 10.1.1.2)

add the following rules:

table=0,ip,actions=ct(table=10,nat)
table=0,priority=10,arp,action=normal
table=10,ct_state=+rel,icmp,actions=resubmit(,20)
table=10,priority=20,ip,ct_state=+trk+new,nw_dst=192.168.2.100,actions=ct(commit,nat(dst=10.1.1.2:80),table=20)
table=10,priority=10,ip,ct_state=+trk+new,actions=ct(commit,nat(src=10.1.1.240),table=20)
table=10,priority=7,ip,ct_state=+rpl,actions=ct(table=20,nat)
table=10,priority=5,ip,ct_state=-rpl,actions=resubmit(,20)
table=10,priority=1,action=drop
table=20,priority=10,ip,nw_dst=10.1.1.1,action=ovs-l0
table=20,priority=10,ip,nw_dst=10.1.1.2,action=ovs-r0

create two connections from left to right:
nc 192.168.2.100 80 -p 10000
nc 10.1.1.2 80 -p 10000

Actual results:
- using kernel dp both connections gets established correctly
- using userspace dp the first connection gets established 

Expected results:
userspace dp should behave like kernel dp