Stop reporting SSL_R_SHUTDOWN_WHILE_IN_INIT.

This effectively reverts b9824e241746d70d985d1004078b5bad0ad9a75b. This
error seems to have mostly just caused confusion in logs and the
occasional bug around failing to ERR_clear_error. Consumers tend to
blindly call SSL_shutdown when tearing down an SSL (to avoid
invalidating sessions). This means handshake failures trigger two
errors, which is screwy.

Go back to the old behavior where SSL_shutdown while SSL_in_init
silently succeeds.

Change-Id: I1fcfc92d481b97c840847dc39afe59679cd995f2
Reviewed-on: https://boringssl-review.googlesource.com/13909
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>

ssl/ssl_lib.c

diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c
index 9bf09df..57178cf 100644
--- a/ssl/ssl_lib.c
+++ b/ssl/ssl_lib.c
@@ -781,10 +781,11 @@
     return -1;
   }
 
-  /* We can't shutdown properly if we are in the middle of a handshake. */
+  /* If we are in the middle of a handshake, silently succeed. Consumers often
+   * call this function before |SSL_free|, whether the handshake succeeded or
+   * not. We assume the caller has already handled failed handshakes. */
   if (SSL_in_init(ssl)) {
-    OPENSSL_PUT_ERROR(SSL, SSL_R_SHUTDOWN_WHILE_IN_INIT);
-    return -1;
+    return 1;
   }
 
   if (ssl->quiet_shutdown) {