provider: use synctest for testing time

[guillaumemichel]

Summary

Refactor tests to use github.com/coder/quartz instead of github.com/benbjohnson/clock or its fork github.com/filecoin-project/go-clock

Refactor tests to use testing/synctest instead of github.com/benbjohnson/clock, its fork github.com/filecoin-project/go-clock or github.com/coder/quartz.

See this blogpost

Benefits

• Better control of time (and goroutines!) in tests
• Deterministic testing (no flakes)
• Faster
• Standard library

[dennis-tra]

A quick fly-by comment because I'm still being notified of all the PRs :D

What about using https://go.dev/blog/synctest instead of introducing another 3rd party lib? synctest is only out since Go 1.25 so I guess it cannot be introduced right away because of the go-libp2p-kad-dht backwards compatibility promise of the latest two Go versions? Or does such promise not exist (anymore)?

[guillaumemichel]

Thanks for the suggestion @dennis-tra, I found a way to run the synctest tests only for go1.25+.

Adapting tests from quartz to synctest isn't too involved. I already converted the connectivity tests to synctest and will proceed to use synctest instead of go-clock for the provider tests too.

The goal is to use synctest wherever needed, and not quartz nor go-clock.

[MarcoPolo]

+1 synctest. Technically not fully deterministic, but that's fine.

remember we have the ability to create simulated networks: https://github.com/libp2p/go-libp2p/tree/master/x/simlibp2p that work with synctest in case its helpful

[dennis-tra]

Technically not fully deterministic, but that's fine.

it's not? do you have a link where I can read up on the details? I had read the linked recent blog post and a few other resources but must have missed that detail.

[MarcoPolo]

```go package main import ( "fmt" "testing" "testing/synctest" ) func TestSyncTest(t *testing.T) { synctest.Test(t, func(t *testing.T) { c := make(chan int, 10) for i := 0; i < 10; i++ { go func(v int) { c <- v }(i) // capture i } for i := 0; i < 10; i++ { fmt.Println(<-c) } }) } ``` There's nothing making the goroutine scheduler deterministic. (shown in example) There's likely also nothing making rand methods deterministic. There's also likely no control in how the OS resumes threads.