Acceptance tests: prevent deadlocks in tests for async writes

[hariso]

Description

Fixes #26

Quick checks:

• I have followed the Code Guidelines.
• There is no other pull request for the same
  update/change.
• I have written unit tests.
• I have made sure that the PR is of reasonable size and can be easily reviewed.

[lovromazgon]

I'm thinking if it would be worth it to add this function as a method to acceptanceTest and to ConfigurableAcceptanceTestDriver 🤔 it would mean it's duplicated, but on the other hand we prevent it from being used anywhere else and keep the package clean.

[hariso]

I was thinking about that too, but I didn't like the duplication at all. On the other hand, maybe it's not a bad thing at all that it's accessible to the rest of the package. I'd maybe move it to a utils package or import it from a library.

[hariso]

Lovro and I talked about this "offline". Similar functionality is needed in other places, so we'll extract this function into a separate file.

[dylanlott]

I saw the comment about pulling the wait utils functions into a separate file or package. I would be in favor of a separate package entirely over a file, especially if these functions are useful concurrency patterns for acceptance tests et. al. Looks good!

[lovromazgon]

Something was bugging me about these functions, bugging me to the point that I took the time to play around with a completely different approach. Here's what I came up with: a9290b4.

The idea is to have types that extend the functionality of sync.WaitGroup and chan with the functionality we need. Even if you use the original type you can cast it to our internal type and use the extended functionality, e.g.:

var wg sync.WaitGroup
err := (*internal.WaitGroup)(&wg).Wait(ctx)
// or
err := (*internal.WaitGroup)(&wg).WaitTimeout(ctx, time.Second)

c := make(chan struct{})
val, ok, err := internal.Chan[struct{}](c).Recv(ctx)
// or
val, ok, err := internal.Chan[struct{}](c).RecvTimeout(ctx, time.Second)

Or you can use the internal types directly (as I did in the commit). WDYT @hariso?

[hariso]

@lovromazgon Nice! I've seen a similar approach in a library I was considering (introducing a dependency for a thing as simple as this wasn't really appealing). Your approach with types is more elegant though! Since we're basically writing our own WaitGroup alternative, we'd need tests for the new as well as the existing WaitGroup functionality. If we can agree the the scope change is OK and pays out, I think it's be cool seeing this merged. 👍

[lovromazgon]

Glad to hear you like the approach.

we'd need tests for the new as well as the existing WaitGroup functionality

I totally agree, I didn't include them since I made the commit more as an exploration to see if it made sense. Do you want me to write the tests or do you want to include the commit in your PR and write tests for it?

[hariso]

FTR, I'll include Lovro's commit into this PR and add tests. I'll convert this PR into a draft to finish another issue first.

[hariso]

We're punting on #26 for now, so I'll close this.