pfcp: Trigger assoc_cb(false) upon Recovery Timestamp change
Signal cp_peer becomes disassociated to the user when the recovery timestamp value changes. The library will automatically try to re-associate after signalling the association change.
cp_peer: Implement local originated heartbeat procedure
Submit PFCP Hearbeat Request with configured interval, and timeout after no PFCP Hearbeat Response received based on configuration.
Upon timeout, the cp_peer assoc_cb() is called to notify the user that the peer is considered not associated anymore. It will then try to keep associating again automatically.
Default value for OSMO_PFCP_TIMER_HEARTBEAT_RESP is increased to 35s to allow for a single Heartbeat Request packet loss.
cp_peer: Implement local originated heartbeat procedure
Submit PFCP Hearbeat Request with configured interval, and timeout after no PFCP Hearbeat Response received based on configuration.
Upon timeout, the cp_peer assoc_cb() is called to notify the user that the peer is considered not associated anymore. It will then try to keep associating again automatically.
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.
