tests: Fix transient failure in ping6 header modify.

The "ping6 between two ports with header modify" test currently
fails 1 in 25 times on an idle system, and apparently 100% of the
time on a more busy system.

The failure appears to be caused by the very first packet to a
new destination being dropped.

Log excerpt:
 ping6 -q -c 3 -i 0.3 -W 2 fc00::3 \
     | grep "transmitted" | sed 's/time.*ms$/time 0ms/'
 -3 packets transmitted, 3 received, 0% packet loss, time 0ms
 +3 packets transmitted, 2 received, 33.3333% packet loss, time 0ms

The fc00::3 address is fully virtual as in it is not assigned
to any interface, the neighbour cache is also pre-populated with
a PERMANENT entry.  So the intermittent failure can not be caused
by neighbour discovery or DAD.

The test does however modify OpenFlow rules immediately prior to
executing the ping6 command, and it is likely that the intermittent
failure is caused by the first ICMP being sent prior to new flow
rules becoming active in the data path.

This patch adds a call to revalidator/wait prior to the first
ping6 check after flow modification.

Reported-at: https://launchpad.net/bugs/2077157
Acked-by: Eelco Chaudron <[email protected]>
Signed-off-by: Frode Nordahl <[email protected]>
Signed-off-by: Ilya Maximets <[email protected]>

tests/system-traffic.at

@@ -253,6 +253,10 @@ priority=0,actions=NORMAL
 AT_CHECK([ovs-ofctl del-flows br0])
 AT_CHECK([ovs-ofctl add-flows br0 flows.txt])
 
+dnl We need to wait until the new flows are actually in the datapath to avoid
+dnl intermittent loss of first ping packet.
+AT_CHECK([ovs-appctl revalidator/wait])
+
 NS_CHECK_EXEC([at_ns0], [ping6 -q -c 3 -i 0.3 -W 2 fc00::3 | FORMAT_PING], [0], [dnl
 3 packets transmitted, 3 received, 0% packet loss, time 0ms
 ])