Fix for TLS dashboard

[thotypous]

Setting up a TLS dashboard currently causes some issues, as initially reported in #5053. Problems were partially fixed by #5055, but some issues remain:

• Setting dashboard_protocol to https causes the dashboard to try accessing Prometheus API though https too. However, Prometheus does not support TLS natively. Setting up a reverse proxy such as nginx would be needed for this. For now, we just fix the protocol as plain http, which is what Prometheus supports.

• People are currently using ceph dashboard set-grafana-api-ssl-verify False as a workaround to get Grafana to work with TLS. In order to get the certificate to validate correctly, we can allow the user to override grafana_server_addr with a FQDN listed in the certificate's CN or altsubjects.

Just for reference, I'm deploying with the following config:

dashboard_protocol: https
dashboard_admin_user: admin
dashboard_admin_password: ommited
dashboard_crt: 'ceph.crt'
dashboard_key: 'ceph.key'
grafana_admin_user: admin
grafana_admin_password: ommited
grafana_crt: 'ceph.crt'
grafana_key: 'ceph.key'
grafana_server_addr: somedomain.ufscar.br

[guits]

@fmount @fultonj @gfidente FYI

[fmount]

@thotypous how can you deal with multiple grafana instances?
One of the main supported scenarios which is the reason to properly compute the grafana_server_addr fact is to allow users defining multiple grafana servers and configuring the ini file using the correct fact computed on the current node in which grafana is deployed.

[thotypous]

Sorry for the delay. I had several issues with the cluster I was using for tests and only got to test the patch against master a few minutes ago.

The previous approach was completely incorrect, sorry. I was originally testing against cae24dd, then took too long to send the PR and messed up when rebasing. I didn't pay attention to the new grafana_server_addrs fact.

@fmount Please take a look at the new approach.