feat: add DNS pre-flight check to verify Docker connectivity before s…

[YashIIT0909]

Add DNS connectivity pre-flight check to relay startup

Description

This PR adds a defensive pre-flight check to ./scripts/start that verifies if Docker containers can correctly resolve external domains before starting the build process.

The implementation:

1. Attempts to connect to dl-cdn.alpinelinux.org from a lightweight temporary Alpine container.
2. Includes retry logic (3 attempts with a 2s delay) to avoid false positives from flaky connections.
3. On total failure, it prints a clear, yellow-formatted warning explaining the likely cause and providing immediate steps to fix it.
4. Non-blocking: The script does not exit on failure; it only warns the user, as the build might still succeed if layers are cached.

Related Issue

#395

Motivation and Context

Linux users (especially on Arch and Ubuntu) frequently encounter DNS bridge conflicts between Docker and systemd-resolved. This usually results in a cryptic EAI_AGAIN error deep in the docker build logs (during apk add or npm install).

By moving this check to the very beginning of the startup script, we provide users with immediate, actionable feedback, saving them time spent debugging low-level Docker networking issues.

How Has This Been Tested?

• Failure Path: Manually disabled host networking to confirm the warning triggers with the correct "Suggested fixes" text after 3 retries.
• Success Path: Confirmed the script proceeds silently (without warning) when connectivity is healthy.
• Tooling: Switched from nslookup to wget --spider to avoid known BusyBox parsing bugs in Alpine that cause false negatives.
• Cleanup: Verified that the --rm flag prevents any orphaned containers from being left behind.

Screenshots (if appropriate):

N/A

Types of changes

• Non-functional change (docs, style, minor refactor)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my code changes.
• All new and existing tests passed.

[cameri]

could you please add some logging here to indicate what is happening to the user?

And can we also set an exponential backoff on the sleep command so it waits 2s the first time, 4s, the second time, and then 8s? Any thoughts?

[YashIIT0909]

I agree that exponential backoff is a more robust way to handle the bridge stabilization period-I’ll implement the 2s/4s/8s sequence.
Regarding the logs, I’ll add the required logging to indicate the status of each attempt.
I'll push the updated code shortly.

[cameri]

should this message go to stderr?
should we use HEREDOC for the multiline message?

[YashIIT0909]

Great points. Sending the warning to stderr is definitely better practice for diagnostic messages, and using a HEREDOC would be a cleaner approach . I'll refactor the block using cat <&2 to address both. Pushing the update shortly !