test(node): Retry initial tedious connection until the DB is ready

[mydea]

The tedious node-integration-test flakes on CI for the same reason the postgres suites did: it opens its DB connection before the database is actually reachable.

Root cause

docker compose up -d --wait blocks only on the container's internal healthcheck. On busy CI the host-side port forward (1433) can lag behind, and MSSQL is especially slow to start accepting connections even after the container reports healthy (the compose file uses start_period: 20s). The scenario called await connect() at the top of run(), before Sentry.startSpan(...) — so a failed initial connect rejected run() outright, no transaction was ever sent, and the test timed out.

Fix

Wrap the initial connect in a small retry loop (connectWithRetry) that keeps trying with a fresh Connection per attempt until the DB accepts it or a 60s deadline elapses. connect() now also closes the failed connection before rejecting so retries don't leak sockets. This is the tedious analogue of the readiness gate the postgres/postgresjs suites use.

Verified locally against the MSSQL container: the suite passes in both ESM and CJS.

Fixes #21620
Fixes #21765
Fixes #21766

🤖 Generated with Claude Code

[sentry]

Bug: Calling connection.close() in the connect event's error handler is risky, as it may trigger an unhandled error and crash the process if the connection state is unstable.
_{Severity: MEDIUM}

Suggested Fix

Remove the connection.close() call from the 'connect' event's error handler. The existing retry logic should be sufficient to handle connection failures by attempting to create a new connection, which is a safer and more consistent pattern.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: dev-packages/node-integration-tests/suites/tracing/tedious/scenario.mjs#L31

Potential issue: In the `tedious` integration test, `connection.close()` is called
within the error callback of the `connect` event. This pattern is known to cause state
machine issues in some versions of the library. If `close()` is called while the
connection is in a transitional state, it may emit its own error. Since there is no
`connection.on('error', ...)` listener attached, this would become an unhandled error
event, causing the Node.js process to crash. This could lead to intermittent test
failures in the CI environment.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[JPeer264]

LGTM