Opportunities for refactoring in GenericContainer

The startup code in GenericContainer seems pretty aggressive in retrying startup failures. I've looked at the code and I'm not sure about the value of some of the things it's doing. I think I may be missing some of the use cases you're trying to support here.

First, there's the inner loop where it waits for the status "running". I've tried this, but I've yet to see a case where a container started up correctly and didn't immediately return "running"... but again, maybe I just haven't seen the use case. It also seems that, since there's no current way to set the container as retrying, if the state is "exited" and the finished at time is not null, it's safe to assume the container will never start up, so we could bail out before the full 30 seconds.

Second, the outer loop, where we retry 3 times. I can't think of a case where the container will fail to start the first time and succeed the second, unless you're starting multiple containers in parallel, or unless the container is flaky - and in the context of an automated test, if something is flaky I'd think that reporting the failure would be more desirable. The retry loop adds complexity, and at least one bug (#102), so I wonder if it would be better to just remove it. Unless, again, there's a use case it supports that I'm not aware of...

Beginne mit dem Lesen des Startup-Codes von GenericContainer und konzentriere dich auf die innere Warteschleife für den Running-Zustand sowie die äußere Wiederholungsschleife mit drei Versuchen, die im Issue beschrieben werden. Ermittle, welche Startup-Zustände und Anwendungsfälle diese Schleifen unterstützen, und validiere anschließend das vorgeschlagene Verhalten anhand der bestehenden Tests und von Issue #102, bevor du den Refactor als abgeschlossen definierst.