The code is checking the sequence number of pdelay-rep and
pdelay-rep-fup, but we may miss the reply and get the f-up.

The result was something like this (first tuple is ok, next is wrong):

   diag-servo-2-wr1: servo:t3 = 1497279009:22584224:0
   diag-servo-2-wr1: servo:t4 = 1497279009:22584574:759
   diag-servo-2-wr1: servo:t5 = 1497279009:23564032:0
   diag-servo-2-wr1: servo:t6 = 1497279009:23564365:547
   diag-servo-2-wr1: ->mdelay = 0:684:306

   diag-servo-2-wr1: servo:t3 = 1497279009:663586672:0
   diag-servo-2-wr1: servo:t4 = 1497279009:22584574:759
   diag-servo-2-wr1: servo:t5 = 1497279009:683142000:0
   diag-servo-2-wr1: servo:t6 = 1497279009:23564365:547
   diag-servo-2-wr1: ->mdelay = -1:-300579732:306

Here, t4 and t6 are old. The former is the receipt of the request,
send back to the "slave" in the pdelay-reply payload; the latter is
the receive time of such frame.

We now invalidate t4 and t5 when using the tuple. They are the two
"remote" times, one sent back in the response and the other sent back
in the response-fup.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>