[fftls] Fix Race Conditions in Unit Tests

[onelapahead]

Occasionally we see builds fail due to "flaky" tests in fftls.

We can recreate locally if we repeatedly run:

 go test -count 1 -v -race ./pkg/fftls/...

We can avoid these failures by:

1. Using a done channel to signal to the listener routine when its safe to stop, and avoid unnecessary errors/panics/logs
2. Avoid polluting the logs with EOF's as those are actually expected
3. Not asserting errors when Writeing, as those might happen if we shutdown right as the listener routine tries to write

Rerunning tests with -race I can't reproduce this issue.

Agentic assistance via cursor_fftls_test_eof_panic_in_gha.md

[onelapahead]

Wondering if we should actually log EOF's here - as they are not expected if we are not <-done now that I think about it.

The bug was that we do a t.Logf after the test completed

[EnriqueL8]

this doesn't make sense, t should still be captured in the context of this go thread..

[EnriqueL8]

or does it get set to nil by the framework?

[onelapahead]

Sorry it never gets nil'ed, its just that if you call Logf on a t who's test has completed, it will panic.

That could occur bc this was in a separate Goroutine that might not shut down quick enough as the test concludes. So the <-done helps prevent all that primarily.

[EnriqueL8]

I see so it's the test framework that panics gotcha

[EnriqueL8]

Thanks for sorting this one out - has been in there for a long time