fix: make EventuallyWithT concurrency safe

[czeslavo]

Summary

In assert.EventuallyWithT, assert.CollectT is used in a concurrent context which may lead to races as explained in #1391.

Changes

We create a CollectT per every condition tick and send its errors over a channel. On the reader side of the channel, we cache the lastTickErrs so they can be copied over to t once the timeout is fired. The only access to lastTickErrs happens in the reader case and the timeout case which both run in the same goroutine.

Motivation

We cannot use EventuallyWithT family of functions/methods in our codebase due to data races it causes.

Related issues

Closes #1391.

[brackendawson]

I was thinking whether this can be fixed by enforcing that condition funcs can never overlap but the documentation is clear that it is checked every tick, so that would be a breaking change. The test relies on the race detector, I don't see a better way to do it.

[dolmen]

So while this effectively serializes calls to CollectT methods (#1418), I'm not convinced this really fixes the core issue.

This implementation doesn't fix the real problem which that we may have multiple instances of the condition function running at the same time (overlapping) but we only use a single CollectT instance to collect the results, with calls to Reset which could alter the result of conditions.

I think we will merge this (with HasErrors made private), but work on EventuallyWithT must not be considered done.

[czeslavo]

So while this effectively serializes calls to CollectT methods (#1418), I'm not convinced this really fixes the core issue.

This implementation doesn't fix the real problem which that we may have multiple instances of the condition function running at the same time (overlapping) but we only use a single CollectT instance to collect the results, with calls to Reset which could alter the result of conditions.

I think we will merge this (with HasErrors made private), but work on EventuallyWithT must not be considered done.

@dolmen Thanks for the comment, you're right! I've taken a look into that again and came up with a solution that doesn't involve a mutex. It also doesn't allow a situation where we end up with an empty CollectT on timeout in case of timeout firing up just after collect.Reset() call. We create a CollectT per every condition tick and send its errors over a channel. On the reader side of the channel, we cache the lastTickErrs so they can be copied over to t once the timeout is fired. The only access to lastTickErrs happens in the reader case and the timeout case which both run in the same goroutine.

[dolmen]

This looks very good!

This is the solution I want!

Also it will allow us to get rid of CollectT which was a design error of the original implementation (a separate work for which I am studying plans since a week).

[dolmen]

As the Reset and Copy methods of CollectT are not needed anymore, and they should have been made private in the first place, please replace their implementation with a panic and add a // Deprecated: comment.

[dolmen]

@czeslavo Note for the future, that completely replacing your original implementation on which at least 2 other people worked too (reviewers) with a completely different one, is not a good practice. It would have been better to open a separate PR and close this one.

Anyway, in this case, the original implementation can be forgotten.

[dolmen]

"address review comments" is never a good commit message. It is completely useless when looking at the Git log or with "git blame". A good commit message must give a summary of what changes, and, if necessary, why. A commit that ONLY says the why is never good.

In the present case squashing the commits is the best thing to do.