[jmx-scraper] support SSL connection with variants

[SylvainJuge]

We need to add support for SSL with the following variants

• server certificate
• client certificate
• RMI registry with/without SSL
• JMX remote profile and realm (see jmx gatherer for details)

Part of #1362

I did some experiments, and there are some unexpected challenges, so I think it's better to describe an implementation proposal to discuss/explain what the implementation will look like.

Implementation proposal:

Currently, testing is split in two parts:

• connection to the remote JVM with JmxConnectorBuilderTest, where testing for those features would naturally fit
• target systems are tested without authentication nor SSL because we only need to check for the captured metrics, not how we connect to the JVM

In JmxConnectorBuilderTest, a target JVM is created and we connect using a local JmxConnectorBuilder instance, which works fine but has some challenges due to docker NAT and JMX/RMI protocols which forces us to find a random available port and then use it for communication between the host and the target JVM (in particular with macOS where the docker containers run in a separate JVM).

In the target systems tests we don't have this issue because the containers communicate to each other directly without any port mapping.

Moving the tests in JmxConnectorBuilderTest to run within a container just complicates debugging without having much benefit for now, but the current "fixed mapped port" strategy we used so far is not possible with SSL as JMX and RMI need to have non-identical ports (otherwise we get "port already in use" errors).

Also, given the complexity of the communication with JMX (authentication, SSL, client and server certificates and their respective keystores, ...) it is also expected that end-users will experience challenges when trying to make it working. So I think we should think about adding a "test connection" feature in the jmx-scraper executable CLI and then test it with a regular integration test, that would only use container-to-container communication. The minor downside here is that the JmxConnectorBuilder testing and debugging will be a bit harder as it will be in a JVM running in a container, but it's an acceptable compromise.

The steps of this plan would be:

• create a new "test connection" feature to CLI, add an integration test for it with current implementation that would replace JmxConnectionBuilderTest
• add support for server certificate
• add support for client certificate
• add support for RMI registry with/without SSL
• add support for remote profile and realm