bug#49449: 28: TLS connection never gets to "open" stage

[Mattias Engdegård]

It seems that the process/TLS apparatus can get into a state where it is unable 
to ever call the process sentinel "open\n" event; specifically, an async 
`url-https` does not make forward progress until the connection times out.

This has been observed on macOS in Emacs 28 now and then, and it looks like 
there is an invariant violation somewhere. To recap:

The "open\n" event is sent to the sentinel in either of two places:

(A) In finish_after_tls_connection, after having successfully called 
nsm-verify-connection and the condition

  (fd_callback_info[p->outfd].flags & NON_BLOCKING_CONNECT_FD) == 0

being satisfied (process.c:3277).

(B) In wait_reading_process_output, after the descriptor being found writable 
by `select` and the condition

    NILP (p->gnutls_boot_parameters) && !p->gnutls_p

being satisfied (process.c:5900).

There seems to be a gap in the logic, however: it is perfectly possible for the 
condition in (A) to fail because the descriptor is still marked nonblocking at 
that point, and for (B) to fail because gnutls_p=true was set already in 
gnutls_try_handshake.

Lars, it looks like you wrote at least part of the original logic. Can you see 
what is going on? It is somewhat complex.

For reference, I'm using the reproduction recipe below; it may or may not 
exhibit the problem in your particular setup. I'm using gnutls 3.6.15.

(defun busy-wait (s)
  (let ((t0 (current-time)))
    (while (< (time-to-seconds (time-since t0)) s) nil)))

(progn
  (url-http
   #s(url "https" nil nil "elpa.gnu.org" nil "/packages/archive-contents" nil 
nil t silent t t)
   (lambda (status) (message "callback: status = %S" status))
   '(nil) nil 'tls)
  (busy-wait 1.0))