fix(ordermatch): ignore loop-back; clear on null root; reject stale keep-alives

[shamardy]

Summary

This PR hardens order matching to prevent “ghost orders” where a cancelled maker order can reappear or stick in the order book.

Changes

• Ignore loop-back messages at process_msg

  • If an incoming message’s pubkey matches the node’s own (persistent or per-order), it’s treated as loop-back and ignored. Prevents acting on echoed versions of our own messages.

• Clear pair on null or hashed-null trie root

  • When a PubkeyKeepAlive advertises a zero or hashed-null root for a pair, delete all local orders for that (pubkey, pair) and persist the null root (“tombstone”) in pubkeys_state.trie_roots. Avoids unnecessary re-sync until a non-null root appears.

• Reject stale/replayed PubkeyKeepAlive by timestamp

  • Track the maker-published timestamp per pubkey (latest_maker_timestamp).
  • Drop PubkeyKeepAlive if message.timestamp <= latest_maker_timestamp to prevent out-of-order/replayed keep-alives from triggering stale syncs.
  • Preserve GC semantics: last_keep_alive remains a local receive timestamp (now_sec()) used by inactivity cleanup.

• Cleanup

  • Removed redundant self-origin checks from downstream handlers (e.g., process_maker_reserved, process_taker_request) since loop-back filtering happens at the entry point.
  • recently_cancelled cache remains unchanged to handle out-of-order messages from other peers.

Impact

• Prevents self-corruption via looped-back messages.
• Blocks stale state from being reintroduced via replayed or out-of-order keep-alives.
• Ensures null-root deletions are remembered and propagated.

QA plan (high level)

• Cancellation propagation: create and cancel a maker order; verify it disappears locally and across peers and does not reappear after network churn or node restarts.
• Null-root handling: after cancellation, verify the affected (pubkey, pair) is cleared and remains empty until a new non-null root is observed (a new maker order is created remotely).
• Replay/out-of-order robustness: under normal network conditions (including transient delays), verify cancelled orders do not reappear and the order book converges across peers.
• Regression checks: normal order creation/updates continue to propagate; inactivity cleanup still purges inactive pubkeys as before. Also make sure that memory on seednodes are not affected and that this fix Seednodes memory leaks fix #1054 is still actual.

Related: #2575

[shamardy]

@cipig this needs to be run for some time to make sure there are no regressions as it changes some things for order matching and syncing.

[dimxy]

Do we know how to reliably reproduce the ghost orders situation (before this fix)?

[cipig]

Do we know how to reliably reproduce the ghost orders situation (before this fix)?

unfortunately i don't... i will bring a seed node back online which i think might have been responsible for triggering this... problem is though that i think that the DC was under DDoS attack by the time this happened (or had other networking issues) and that's a thing that i can't reproduce

[dimxy]

Looked thru the fix, like it.
LGTM

[mariocynicys]

LGTM!
Thanks

[shamardy]

@cipig I will merge this and we can test it in dev