Never give up in socket transport

[mrubens]

Important

Allow infinite retry attempts in SocketTransport by setting maxInitialAttempts to Infinity and adjusting connection state handling.

• Behavior:
  • Set maxInitialAttempts to Infinity in SocketTransport to allow infinite retry attempts.
  • Removed logic that set connectionState to FAILED after exhausting retry attempts.
  • Adjusted error logging to reflect unexpected errors in the connection loop.
• Logging:
  • Removed max attempt count from connection attempt logs in connectWithRetry().
  • Changed reconnect_failed event to set connectionState to RETRYING instead of FAILED.

^{This description was created by for 989fb2e. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Thank you for your contribution! I've reviewed the changes and found several issues that need attention before this can be merged.

[roomote]

Is setting this to Infinity intentional? The while loop in connectWithRetry() will never exit naturally now, which could lead to resource exhaustion if the connection continuously fails. Consider:

1. Making this configurable through the constructor's retryConfig parameter
2. Adding a mechanism to cancel retry attempts (e.g., an abort signal)
3. Implementing exponential backoff with a maximum retry duration instead of infinite attempts

[roomote]

This error message might be misleading now. With infinite retries, errors in the connection loop aren't necessarily "unexpected" anymore. Could we update this to be more descriptive, like "Error in connection retry loop" or "Connection retry loop terminated unexpectedly"?

[roomote]

With maxInitialAttempts now set to Infinity, this while condition will always be true. Should we add an additional exit condition here, such as checking for a cancellation signal or a maximum retry duration?

Also, the removed code that threw an error after max attempts provided a clear exit condition. Without it, the only way to exit this loop is through a successful connection or an unexpected error.

[roomote]

Is setting the state to RETRYING here intentional? Socket.IO has already exhausted its reconnection attempts at this point. This might confuse consumers checking the connection state, as it implies retrying is still happening when it's not. Should this remain as FAILED or perhaps a new state like AWAITING_MANUAL_RECONNECT?