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.
