avoid race conditions by waiting one polling interval

[gflarity]

What does this PR do?

I've observed intermittent failures with TestShouldStartContainersInParallel. After digging into it I realized that there's a race in http WaitUntilReady. There's a brief period of time where no error is returned, but the external port hasn't been bound yet. To fix this I simply updated the logic so that one interval passes before we check the ports for the first time. This seems to do the trick and the test doesn't fail intermittently for me now.

The interval time still seems like an arbitrary sleep though. I also tried a different solution which retried until the port gets bound (or context timed out), but then you would need to either:

1. Change multiple other tests to accommodate timeouts and get rid entire concept of "No exposed tcp ports or mapped ports - cannot wait for status" errors, as these would cease to exist.
2. Introduce some sort of separate port binding timeout concept, which would change the API.

I think 1) probably makes the most sense to me. Waiting for http on a container with no exposed ports seems like it should timeout. But this would be a much bigger change.

Why is it important?

Intermittently failed tests make it hard to develop :)

Related issues

N/A

[netlify]

✅ Deploy Preview for testcontainers-go ready!

Name	Link
🔨 Latest commit	fbe9c28
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-go/deploys/6515ec76d5dd3b0008f514d3
😎 Deploy Preview	https://deploy-preview-1697--testcontainers-go.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mdelapenya]

Thanks for taking the time to look at this issue. Race conditions are always hard to find/debug/fix, so all my gratitude for your work here.

LGTM!