feat: add csr-domain-name config option (#381)

[DnPlas]

feat: enable csr-domain-name config option so istio-pilot can use it on CSRs

The istio-pilot charm already has a mechanism in place to discover the ingress gateway address from the Service, but it is limited to only returning IP addresses, which not all TLS certificate providers accept as a valid cert subject. Having the domain-name config option will allow users to specify the domain name they'd like to use when integrating with TLS certificate operators. This feature expands the support for integrating with TLS certificate providers that cannot issue signed certificates on a CSR that only contains an IP address (like we used to do). This commit also adds some test coverage to test the recently added code.

Fixes #379

NOTE: CI may fail because of #385 and #384

Testing instructions

Assuming you've got a microk8s deployment with
Ensure the upgrade is done correctly:

1. Deploy istio-operators

juju deploy istio-gateway istio-ingressgateway --config kind=ingress --channel 1.17/stable --trust
juju deploy istio-pilot --channel 1.17/stable --trust
juju relate istio-pilot istio-ingressgateway

2. Wait for them to be active and idle
3. Refresh istio-pilot to the version in this PR juju refresh istio-pilot --channel latest/edge/pr-386 --revision <check-revision-in-CI>
4. Ensure no errors are logged

Ensure the certificate has the correct domain name

1. Deploy juju deploy self-signed-certificates
2. Relate juju relate self-signed-certificates istio-pilot
3. Change CSR domain name juju config istio-pilot csr-domain-name="istio-test.com"
4. Check the certificate subject, it should be the same as the csr-domain-name that was set in (3)

# Get the issues certificate, look for it in the unit
$ juju show-unit istio-pilot/0
...
  - relation-id: 0
    endpoint: peers
    related-endpoint: peers
    application-data: {}
    local-unit:
      in-scope: true
      data:
        certificate: |-
          -----BEGIN CERTIFICATE-----
         ...
          -----END CERTIFICATE-----

# Check the subject name
$ openssl x509 -noout -subject -in ca.cert <--- you can save the cert in a file and pass it here
subject=CN = istio-test.com, x500UniqueIdentifier = abfd61dc-629d-4eaa-9b19-9613908e0313

[DnPlas]

It seems like the CI issue is related to the charmcraft version and the charmcraft.yaml we have in place. Please refer to #387 for more details. That PR should be merged for the CI in this one to pass.

The CI issues are caused by:

1. The kubeflow-volumes pointing at latest/edge which now need to be trusted. Please refer to tests: pin kubeflow-volumes to its 1.8/stable channel #388 for details and a fix.
2. charmcraft latest/edge introducing a check for the length of the summary charmcraft pack fails with a false positive on the summary check charmcraft#1568. Please refer to fix: shorten the summary as a workaround for canonical/charmcraft#1568 #389 for details and a fix.

Both PRs should be merged before the CI in this one passes.

[NohaIhab]

followed testing instructions successfully,
LGTM!

[Barteus]

I deployed the charms with CKF 1.8, as described above and got this error in oidc-gatekeeper:

2024-03-21T15:59:37.856Z [oidc-authservice] time="2024-03-21T15:59:37Z" level=error msg="OIDC provider setup failed, retrying in 10 seconds: Get \"https://10.64.140.43.nip.io//dex/.well-known/openid-configuration\": tls: failed to verify certificate: x509: certificate is valid for istio-pilot-0.istio-pilot-endpoints.kubeflow.svc.cluster.local, not 10.64.140.43.nip.io"