Add support for blocking 'entrypoints'

[samruddhikhandale]

As the entrypoints are long lived, the entrypoint scripts runs in the background. Hence, this is not a blocking script for the container startup.
Can we add a new semantics to have "blocking" entrypoints that the CLI waits for?

Scenario: We have seen flakiness in docker startups for docker-in-docker Feature where docker is not running in the container. See devcontainers/features#634 and devcontainers/features#660.

devcontainers/features#669 adds few retry mechanisms to attempt to fix this issue. /usr/local/share/docker-init.sh which starts/retries dockerd is added to the entrypoint command. This command runs in the background and is not a blocking script for the container startup. Since it's in the background, onCreateCommand/postCreateCommand/postStartCommand could all start executing before docker is fully running. If it takes docker too long, that could introduce flakiness in those lifecycle scripts. Hence, it would be great to have some way of adding a blocking entrypoint to ensure dockerd is ready for the container (including the ^ lifecycle scripts)

// cc @chrmarti

[joshspicer]

Perhaps we could change the definition of the waitFor property to include entrypoint, informing the CLI to block further execution on Feature-provided entrypoint scripts to complete.

ie, in the implementation write a marker file or similar after this point

[chrmarti]

One difficulty is that multiple features can have entrypoints that need to be waited for. As a first approximation, could a feature add an onCreateCommand that waits for its entrypoint to be ready?

[joshspicer]

+1 to exploring the onCreateCommand as the stop gap solution. There's already some work here devcontainers/features#710