fix(gossipsub): prevent erroneously duplicate message IDs

[dariusc93]

Description

Previously, we only mutably borrowed the last_seq_no in the current scope but did not modify the underlying number. This is because u64 is copy and calling wrapping_add consumes self so the compiler just copied it. We introduce a new-type instead that is not Copy.

Additionally, wrapping_add and initializing with a random u64 might actually warp the number and thus not give us sequential numbers as intended in #3551. To solve this, we initialize with the current unix timestamp in nanoseconds. This allows a node to publish 1000000 messages a second and still not reuse sequence numbers even after a restart / re-initialization of the configuration. This is also what the go implementation does.

Resolves #3714.

Co-authored-by: Thomas Eizinger [email protected]

Notes & open questions

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[thomaseizinger]

I updated the title and PR description, let me know if I understood the problem and fix correctly!

[thomaseizinger]

cc @divagant-martian In case you are also upgrading to 0.51.2 already.

[thomaseizinger]

Lockfile needs updating!

[thomaseizinger]

I've pushed an improved fix that should make handling this slightly safer.

cc @AgeManning I've also changed this to start with the current time. The thinking was that if we want to be strictly increasing, wrapping_add is the wrong function as we might actually not increase the sequence number if we start with a really high random number. Instead, I am using milliseconds of the current unix timestamp. This means, even if a node would start and burst out messages, then shut down and start again, they have to send more than 1000 messages per second before they'd get into a state where they'd send out messages that other nodes perceive as duplicates. I think that is reasonably safe.

I also chose to expect the wrapping. Even if we send 1 million messages a second, we'd only run out of space after 584942 years if my calculation is correct.

[thomaseizinger]

cc @MarcoPolo This PR changes our implementation to be the exact same as go.

[AgeManning]

Yep this makes sense to me, the panic at u64::max() is for someone living 600k years in the future's problem (if they can keep a libp2p node running that long without updating :).)

This also doesn't effect us as we don't use sequence numbers, so all good from our end, thanks for the ping :).

[thomaseizinger]

Thank you @dariusc93 for the initial discovery of the bug and the pull request.

[mxinden]

Thanks @dariusc93 for debugging and proposing a patch!

---

@thomaseizinger shall I cut a new patch release already, or do you want to wait for #3625?