Respond to TLS certificate/key changes without requiring a restart

[legrego]

Kibana maintains a number of different TLS configuration settings:

• Kibana's own HTTP server ([HTTP Server] support TLS config hot reload via SIGHUP #171823)
• Kibana's connection to Elasticsearch
• Kibana's connection to the monitoring cluster (when Stack Monitoring is in use)
• Kibana's connection to the Enterprise Search service
• Kibana Alerting (TODO)

TLS certificates and keys are generally stored on disk, read once on startup, and used for the lifetime of the process. Changes to these files will not be picked up until Kibana is restarted.

Elasticsearch has long supported reloading this configuration from disk -- we should explore the feasibility of similar support within Kibana, so that we can accept updated certificates/keys without a restart.

Support for this would greatly simplify certificate rotation in managed environments such as ESS and ECE

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[jportner]

Note for posterity:

Before I merged #53810 (in the 7.6 release), every time a certificate config value was read by a consumer, it was read off of the disk. So it was possible to change a certificate on the filesystem while Kibana was running, and get into a situation where some consumers were using the old cert, and some were using the new one. That PR included a change to read the cert off of disk when Kibana starts and keep the PEM file in memory.

[legrego]

Closing in favor of #54368

[pgayvallet]

Reopening, as #171823 only fixed the first point (Reloading Kibana http certificates), and this issue was more broad than #54368

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

Regarding reloading the Kibana<->ES certificates, proposal on how it could be done started here: #110082 (comment)