Stats: Add JVM dns cache expiration config to JvmInfo

[spinscale]

The java security manager disables the DNS cache by default and never
expires any DNS entry. The default behaviour without the security
manager is 30 seconds.

In dynamic environment DNS entries can change, which means, that an
Elasticsearch instance requires a restart to pick up new settings.

Right now, there is no visibility to find out, if/how the configuration
for DNS expiration is set.

This adds this info to the JvmInfo class. Either the setting is shown or
it is marked as 'unlimited'

[elasticmachine]

Pinging @elastic/es-core-features

[spinscale]

Testing is a bit hard as it requires JVM config changes. I tested this by setting the following in $JAVA_HOME/conf/security/java.security

networkaddress.cache.ttl=30

one more thing we could think about as well is to configure this setting in Elasticsearch using java.security.Security.setProperty("networkaddress.cache.ttl" , "30"); and thus restore the original behaviour or make this available as a setting, so that users do not have to change their JVM configuration.

[jakelandis]

As you mention in the comment... I think it is safe to grab the property here, set it to the the desired value, test it, then set it back to the original value in a finally block. Assuming we don't execute any of the unit tests within the same JVM concurrently (I don't think we do, but not 100%).

[spinscale]

@elasticmachine retest this please

[jasontedor]

After #36570 I am not sure if we need this anymore?

[spinscale]

I think this still might help to quickly check the authoritative setting independent from the JVM args, i.e. in case of support - even though it is now more likely that the defaults are used?

[spinscale]

After discussing this one more time yesterday: I thought about this over sleep and I agree we do not need it. The corner case that this can catch will be extremely rare in the future (unless different JDK distributions decide to change default behaviour, which I consider unlikely AND the user has removed the options in the configuration file).

As we can easily detect a configuration change by checking the jvm.options file (or the nodes info output) we can go from there in the future and debug further.

I will close this.