datapath-windows: check source port during tunnel Tx

In the Windows datapath, Tx tunneling functionality is implemented by checking
if the outport in the action is a tunnel port. If so, the packet is
encapsulated and sent out on the PIF bridge for as second flow lookup.
Basically, we don't use the hypervisor's IP stack to send out a packet, and
short circuit the path ourselves. On the PIF bridge, the source port of the
encapsulated packet is the VTEP port ie. the internal port.

If a Tunneling port is added to the PIF bridge (a possible misconfiguration),
where the VTEP(internal) port and the external port (physical NIC) also reside,
a flooding action can cause a loop, by re-injecting the packet on the same PIF
bridge which again floods to the tunnel port.

In this change, we break the loop by encapsulating packets only if they are
sent out by a VIF or if they originate from userspace ie. userspace generated.
We make use of the input port attribute in the packet execute ioctl.

This change is based off of the legacy datapath interface published in
OvsPub.h. This interface has a input port field in the packet execute ioctl.
I looked in dpif-linux.c that uses the netlink based datapath interface and
even in that case, we do add the the source port in:
    dpif_linux_encode_execute() -> odp_key_from_pkt_metadata().
So, this fix is applicable when we adopt the netlink based datapath interface
as well.

The Rx side of OvsDetectTunnelPkt() has only documentation updates. The fix is
on the Tx side.

Validation (using dpif-windows.c):
- Was able to perform VTEP <-> VTEP ping with the configuration posted in the
issue.
- Was able to perform VIF <-> VIF ping when the setup was configured correctly.

Signed-off-by: Nithin Raju <nithin@vmware.com>
Reported-by: Alin Serdean <aserdean@cloudbasesolutions.com>
Tested-by: Alin Serdean <aserdean@cloudbasesolutions.com>
Reported-at: https://github.com/openvswitch/ovs-issues/issues/20
Signed-off-by: Ben Pfaff <blp@nicira.com>