bug#26835: 26.0.50; url-retrieve no longer raises certificate errors

[Eli Zaretskii <eliz@gnu.org>]

[Resending, as I messed up the previous message.  Apologies.]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Mon, 8 May 2017 12:44:52 -0700
> Cc: 26835@debbugs.gnu.org
> 
> It repros in `emacs -Q', just set:
> 
> (setq gnutls-verify-error t)
> (url-retrieve-synchronously "https://wrong.host.badssl.com/")
> 
> In Emacs 25.2, this causes an error to be thrown when you use
> url-retrieve, in 26, it silently proceeds.

That's because we now perform GnuTLS negotiation asynchronously,
without blocking.  When the certificate matching fails, gnutls.c
faithfully stores the error message in the process's status by calling
boot_error:

	      boot_error (p, "The x509 certificate does not match \"%s\"",
			  c_hostname);

and boot_error does:

  static void ATTRIBUTE_FORMAT_PRINTF (2, 3)
  boot_error (struct Lisp_Process *p, const char *m, ...)
  {
    va_list ap;
    va_start (ap, m);
    if (p->is_non_blocking_client)
      pset_status (p, list2 (Qfailed, vformat_string (m, ap)));

So the process status becomes the list (failed "error message").  But
when url-retrieve-synchronously accesses the status, by calling
process-status, we do this:

  status = p->status;
  if (CONSP (status))
    status = XCAR (status);

which loses the error message, leaving just 'failed'.  So
url-retrieve-synchronously silently exits, and doesn't even have the
info that could cause it to signal an error.

IOW, the problem is not that the connection proceeds -- it does not.
The problem is that it fails silently without telling the caller what
caused the failure.

I'll CC Lars, who introduced the non-blocking connections.