Split stateless NAT stage into two

[Fredi-raspall]

There are certain combinations of NAT within a peering that will not work today the way the network functions are organized, since the execution order matters. One solution to the problem is splitting the stateless NAT NF into two (one for source, one for destination) and placing them at the opposite sides of the pipeline (sourceNAT + NF + NF ... + DstNAT).

[qmonnet]

As it turns out, something like source NAT + NF + NF ... + destination NAT doesn't work so well, because not all NAT modes require the same order.

For example, if we did the flow table lookup in the port forwarding stage, static NAT + port forwarding would need:

1. Static NAT for destination address (reverse path only)
2. Port forwarding (destination for forward path, source for reverse path)
3. Static NAT for source address (forward path only)

But static NAT + masquerading would need instead:

1. Static NAT for source address (reverse path only)
2. Port forwarding (source for forward path, destination for reverse path)
3. Static NAT for destination address (forward path only)

We could have both optional source and destination static NAT before, and then after, the port forwarding and masquerading stages. But even then, it doesn't work, because the flow table lookups are not in the port forwarding or masquerading stage, but at the "beginning" of the pipeline before the packet has been through the flow filter and static NAT stages. The way I could make this work is by keeping track of the initial IP addresses of the packet to construct the right flow table entries to use. See #1548.