client: happy eyeballs: retire the primary socket when a racer wins

[saghul]

Found while implementing the new parallel-connect event lib ops (d31f2d830 "event-loop: HE races") in a custom event lib driving lws off a libuv loop.

When a racing (parallel) connect is seen to have completed, the LCCCR_CONNECTED path in lws_client_connect_3_connect() promotes it with promote_parallel_fd() alone:

			case LCCCR_CONNECTED:
				...
				lws_sul_cancel(&wsi->sul_happy_eyeballs);
				if (pidx != -1)
					promote_parallel_fd(wsi, pidx);

Nothing removes the primary socket from the fds table or closes it. promote_parallel_fd() then moves wsi->position_in_fds_table to the racer's slot, so the primary's slot is orphaned: it still maps the primary fd to this wsi, but any later __remove_wsi_socket_from_fds() on the wsi targets the racer's slot instead, so that entry can never be removed.

Observable effects:

• pt->fds never drains, so the

  while (pt->fds_count) {
          struct lws *wsi = wsi_from_fd(context, pt->fds[0].fd);
          if (wsi) { lws_close_free_wsi(wsi, ...); ... }
  }

  loop in lws_context_destroy() spins forever at 100% CPU (the wsi it finds is closed over and over, and its position never matches slot 0). Caught with sample as an endless lws_context_destroy → __lws_close_free_wsi cycle.

• the primary socket is leaked.

The conn_good is_parallel path already does this correctly (remove from fds, then promote_parallel op or compatible_close, then promote_parallel_fd); this change makes the LCCCR_CONNECTED path do the same. __remove_wsi_socket_from_fds() already fixes up parallel_conns[].position_in_fds_table when it moves the end entry into the hole, so the remaining racers' slots stay correct.

How easily it is reached, once an event lib implements the parallel ops: on Windows the win32_sul_connect_async_check sul probes racer fds directly, so any racer that connects before a slow primary lands here; on POSIX it needs the companion fix that gives the racing fd its POLLOUT.

Tested on macOS with a libuv-based event lib implementing the parallel ops and the happy-eyeballs delay temporarily forced to 1us, so every multi-address connect races and racers routinely win: before, the process spins at exit after the fetch completes; with this plus the POLLOUT fix, four https fetches complete and the process exits promptly. Full test suite (329 tests) green, ASAN clean.

[saghul]

Related happy-eyeballs / parallel-connect fixes from the same investigation, all independent of each other: #3648 (racing fd gets the POLLOUT), #3649 (primary retired when a racer wins), #3650 (fds-removal io stop routed through the parallel ops).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud