[TT-1928] improve startup retry logic

[Tofel]

now we will not change container name on startup retry, but delete old container instead, as new name creates connection problems for containers that depend on the restarted one (they do not know, they need to connect to it using the new name).

This happened here, where startup retry worked, but CL node didn't find the new container.

---

Below is a summarization created by an LLM (gpt-4-0125-preview). Be mindful of hallucinations and verify accuracy.

Why

The changes improve the container retry mechanisms in our Docker library by introducing a more robust error handling and cleanup process before retrying container starts. Specifically, it addresses scenarios where a container fails to start due to image or platform compatibility issues, ensuring a fresh attempt is made without reusing the problematic container.

What

• lib/docker/docker.go
  • Added context, container from github/docker/docker/api/types, and errors from github/pkg/errors imports to support new error handling and container removal logic.
  • Modified NaiveRetrier and LinuxPlatformImageRetrier functions to remove the existing container before retrying to start a new one. This involves setting req.Reuse to false and calling a new removeContainer function if an error occurs during container start.
    • This change ensures that any retry attempt to start a container is done with a fresh environment, preventing the reuse of a potentially corrupted or misconfigured container.
  • Added a new removeContainer function that attempts to remove a container by its name using the Docker provider. It handles errors gracefully, ignoring the error if the container does not exist, ensuring the function only intervenes when necessary to clean up resources.
    • This function supports the retry mechanisms by ensuring that any resources tied to a failed container start attempt are cleaned up before a new attempt is made, thereby increasing the likelihood of a successful container start on subsequent retries.

[cl-sonarqube-production]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube