🪵Log TLS shutdown error🛑, only if any

Describe the bug

Currently, we call boost::asio::ssl::stream::async_shutdown() and ignore the error. We shall log it!

But only if there's an actual error, i.e not a false positive which unnecessarily scares the user. Currently we even have such:

To Reproduce

--- lib/remote/jsonrpcconnection.cpp
+++ lib/remote/jsonrpcconnection.cpp
@@ -253 +253,7 @@ void JsonRpcConnection::Disconnect()
-                       m_Stream->next_layer().async_shutdown(yc[ec]);
+                       {
+                               boost::system::error_code ec;
+                               m_Stream->next_layer().async_shutdown(yc[ec]);
+
+                               Log(LogCritical, "JsonRpcConnection")
+                                       << "API client disconnected for identity '" << m_Identity << "': " << ec.message();
+                       }

With this patch, running (echo '1000000:'; cat /dev/zero) |openssl s_client -connect 127.0.0.1:5665 against Icinga 2 results in:

[2024-11-26 18:04:16 +0100] critical/JsonRpcConnection: API client disconnected for identity '': application data after close notify (SSL routines)

This is due to how Boost ASIO shuts down SSL – it (often) calls SSL_shutdown() twice. Once for notifying the peer and the second time to mark the connection as shut down. The peer may even not have time to ack the termination. And when it does, we're passively aggressive via the above log message.

Expected behavior

1. Call SSL_shutdown() once
2. Read, via Boost ASIO, until EOF (replaces second SSL_shutdown() call)
3. Log the damn error if still any :)

Screenshots

Your Environment

Include as many relevant details about the environment you experienced the problem in

• Version used (icinga2 --version): master
• Operating System and version: latest MacOS
• Enabled features (icinga2 feature list): api
• Icinga Web 2 version and modules (System - About): -
• Config validation (icinga2 daemon -C):
• If you run multiple Icinga 2 instances, the zones.conf file (or icinga2 object list --type Endpoint and icinga2 object list --type Zone) from all affected nodes.

Additional context

Digged out by @julianbrost IIRC.

Start in lib/remote/jsonrpcconnection.cpp at JsonRpcConnection::Disconnect() and inspect the async_shutdown() flow used by the API connection. Reproduce the behavior with the provided openssl s_client command, then verify that shutdown reads through EOF and logs only a genuine remaining error without the false-positive message.