ApiListener: Log connection attempts from an already connected client prominently

[yhabteab]

Something is definitely going wrong if a client tries to reconnect to this endpoint while it still has an active connection to that client. So we shouldn't hide this, but at least log it at info level. Apart from that, I've added some additional information about the currently active client, such as when the last message was sent and received.

Tests

Start two Icinga 2 endpoints and try to connect to one of them using either ones certificate.

echo -n '86:{"jsonrpc":"2.0","method":"icinga::Hello","params":{"capabilities":3,"version":21400}}\r\n\r\n' | openssl s_client -connect localhost:5665 -cert satellite.crt -key satellite.key

Logs on the master endpoint:

[2024-10-30 11:47:10 +0100] information/ApiListener: New client connection for identity 'satellite' from [::1]:58029
[2024-10-30 11:47:10 +0100] information/ApiListener: Ignoring JSON-RPC connection from [::1]:58029. We're already connected to Endpoint 'satellite' (last message sent: 2024-10-30 11:47:09, last message received: 2024-10-30 11:46:33).

[yhabteab]

@julianbrost please also give your thoughts on this, especially on whether a log info level is enough or should be promoted to warning. I didn't want to log it as a warning because the end user is neither responsible for this nor can do anything to fix it.

[julianbrost]

No strong opinion there on my side. Increasing it to info definitely makes sense. Currently, with the "New client connection for identity" at level info, there's otherwise little hint that this connection was closed immediately.

Going to warning, well yes, this message could be a hint that there's something funky. I presume you've created this PR because you're currently debugging a connection-related issue where you don't really know why this happens. So until we understand that issue, we couldn't provide a good answer to the question "what to do about this warning", thus, info sounds fine for the moment. If we better understand the issue and what to do about it, we can still bump it to warning (and ideally fix the underlying issue and/or provide more helpful information on what's actually wrong in the log message).