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...

Start by reading the GenericContainer startup code, focusing on the inner wait-for-running loop and the outer three-attempt retry loop described in the issue. Determine which startup states and use cases those loops support, then validate the proposed behavior against the existing tests and issue #102 before defining the refactor as complete.