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

まず GenericContainer の startup コードを読み、issue で説明されている内側の running 待機ループと外側の 3 回試行の retry ループに注目してください。これらのループがサポートする startup 状態とユースケースを特定し、refactor の完了を定義する前に、既存のテストと issue #102 に照らして提案された動作を検証してください。