There are two ways moving forward:

• One is to always use the callback invocation pattern that's currently taken only when certificate verification fails. At the moment, that path fails, because when the user calls h2o_socket_close, invocation of SSL_shutdown returns an error and then the connection object is discarded without sending what's in the send buffer. Pros of this approach is that the code is concise, as we can get rid of the if that depends on the behavior of OpenSSL. The downside is that the state of st_h2o_socket_ssl_t would be different between OpenSSL versions (i.e., we'd be calling the handshake completion callback while there's something in the output buffer, if OpenSSL 1.1.0 or above is used). This PR adopts this approach.
• The other is to always use the callback invocation path that's currently taken when TLS handshake fails due to reasons other than certificate verification error. The pros is that the internal state would be consistent. The downside is that the moment to extract X.509 error would be different between the OpenSSL versions, see send TLS alert before closing the socket, when OpenSSL is used and certificate verification fails (alternative to #2910) #2911.

Closing in favor of #2911.