Fix lstk start waits forever when the container fails during startup

[tiurin]

Motivation

lstk start kept waiting at "Starting LocalStack..." indefinitely when the container failed during startup (e.g. in offline/DNS-broken environments), and never surfaced the container's exit code or logs.

Changes

Before: ∞ "Starting LocalStack..." without any actionable information.

After: If after 20 seconds LocalStack hasn't started lstk prompts to keep waiting or stop, suggesting to look at lstk logs as well. In non-interactive mode the timeout is 60 seconds upon which lstk reports a failure and leaves the container running for inspection.

Note: 3 second timeout is used for the video for the sake of brevity. 20 seconds felt like a good default for me, LocalStack should generally start faster as a local tool. Happy to adjust if there is any better idea about the default.

devx-758.mov

Changes details

• Register a next-exit container wait between create and start, so the exit code is captured even for instantly-exiting containers before --rm removes them; Runtime.Start now returns the exit channel and awaitStartup consumes it alongside the existing health/liveness poll
• Bound the readiness wait with a startup deadline: 20s interactive, 60s non-interactive (more relaxed for CI use case to allow for slower machines and also CI is a more patient user), overridable via LSTK_STARTUP_TIMEOUT
• On the interactive deadline, prompt Keep waiting [W] (re-arms the deadline) / Stop LocalStack and exit [S] (stops with progress feedback); non-interactive fails and leaves the container running for inspection
• Surface both failure modes with the exit code and last container log lines (read after the log-tail drain so the tail is complete), with messaging that reflects whether the container was stopped; add a start_timeout telemetry error code

Tests

• New integration tests: a container that exits during startup fails with the reported exit code; a running-but-never-healthy container fails after the configured timeout (previously hung forever)
• New unit tests: exit-code delivery, poll fallback when the wait fails, timeout, the interactive keep-waiting/stop prompt flow, and per-mode default resolution

Closes DEVX-758

[tiurin]

Will push a bit of a refactoring shortly.

[tiurin]

I'm not too happy with the function parameters count growing so much in awaitStatus and handleStartupTimeout/Faillure. Will refactor this to put dependencies that are constant for the whole Start invocation to a struct: rt, sink, tel, timeout, interactive. And then keep only per-call data as function agruments: containerID, healthURL, exitCh, c, err, logs

[tiurin]

Refactored in 6ffb089

[anisaoshafi]

Thank you for your contribution, Misha 👏🏼

small issue: before if CTRL+C called while awaiting it still did emit and send a telemetry event which is a sort of regression in this PR. Not a big deal, but if there's a reason for it, would be nice to assert it in some test so we recall the decision, or otherwise just try to track that event.

[tiurin]

Thank you for your contribution, Misha 👏🏼

small issue: before if CTRL+C called while awaiting it still did emit and send a telemetry event which is a sort of regression in this PR. Not a big deal, but if there's a reason for it, would be nice to assert it in some test so we recall the decision, or otherwise just try to track that event.

Thanks for spotting this @anisaoshafi! Restored the telemetry event in 79db60e