Changes

Avoid marking rx PFCP Assoc Setup Req as duplicate

Newer versions of PFCP spec state that "A PFCP
function shall ignore the Recovery Timestamp
received in the PFCP Association Setup Request message."

Hence, there's no real way to make sure an incoming PFCP ASSOC
SETUP REQ is a duplicate or is simply a new message from a new instance
of the peer node which "decided" to use the same SeqNr as the previous
one. In that case, it's better to be on the safe side and process it to
tear down state rather than ignoring it and keeping old state. If it
turns out to be a duplicate (rare scenario), we'd maybe tear down some
stuff which would have been set up a few seconds ago.

Change-Id: Ia461550e6791aaf00d18e0310bb4f17fdd2a3f65