refactor: use secret config instead of action for configuring TLS ingress gateway

[DnPlas]

⚠️ WARNING: This feature has been added due to #380, but will be supported only in 1.17 and 1.22 (and the versions released in between, iff any), after that, it will be removed in favour of integrating with a TLS certificates provider. Documentation will be provided for upgrades and migrations.

The recommended way of handling user secrets is by saving the user secret ID in a charm configuration, that way the charm can use it to get the contents of the secret. When the charm is granted with the user secret via the CLI, it allows the charm to observe secret events, which help handle changes in their contents. The istio-pilot charm implemented a way to use actions to wrap the secret logic, but because of the above, this commit does a small refactor to remove the set-tls and unset-tls actions and instead use user secrets directly.

This commit also renames ssl to tls to be more accurate when referring to the actual configuration that gets done in the Gateway.

Part of #398

Merge after #402

Manual testing

NOTE: this feature works with juju > 3.3, installing and bootstrapping a controller version 3.4 is recommended to be in sync with the CI (changes introduced by #402).

• Add a secret to configure Ingress Gateway with TLS

1. Build and deploy the charms from this branch. Relate them and wait for them to become active and idle.
2. Add a user secret juju add-secret istio-tls-secret tls-crt=<some str> tls-key=<another str>
3. Grant access for istio-pilot to access the secret contents juju grant-secret istio-tls-secret istio-pilot
4. From the output of command in step 2, pass the secret ID to the istio-pilot charm as a config option with juju config istio-pilot tls-secret-id=secret:<secret ID resulting from step 2>. If you have lost it, you can always check with juju secrets.
5. Wait for the charm to become active and idle
6. Verify the Gateway resource is configured with TLS and that the Secret (the kubernetes resource) has the expected values:

$ kubectl get gateways -n istio-secrets istio-gateway -oyaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  creationTimestamp: "2024-03-18T13:01:38Z"
  generation: 6
  labels:
    app.juju.is/created-by: istio-pilot
    app.kubernetes.io/instance: istio-pilot-istio-secrets
    kubernetes-resource-handler-scope: gateway
  name: istio-gateway
  namespace: istio-secrets
  resourceVersion: "46454"
  uid: 57374582-c0fd-4b80-96e8-138196371cf9
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: https
      number: 8443
      protocol: HTTPS # <---- it is now using HTTPS
    tls:
      credentialName: istio-gateway-gateway-secret # <---- It is now pointing at a secret
      mode: SIMPLE
$ kubectl get secret -nistio-secrets istio-gateway-gateway-secret -oyaml
apiVersion: v1
data:
  tls.crt: YmFy # <--- base64 encoded string
  tls.key: Zm9v # <--- base64 encoded string
kind: Secret
metadata:
  creationTimestamp: "2024-03-18T15:24:48Z"
  labels:
    app.juju.is/created-by: istio-pilot
    app.kubernetes.io/instance: istio-pilot-istio-secrets
    kubernetes-resource-handler-scope: gateway
  name: istio-gateway-gateway-secret
  namespace: istio-secrets
  resourceVersion: "46453"
  uid: f77394a2-a773-4407-8c1f-eb6a18db996c
type: kubernetes.io/tls

• Check the TLS configuration changes if the secret changes

1. Change the secret contents juju update-secret secret:<secret id> tls-crt=new-crt tls-key=new-key
2. Check a secret-changed`` message in juju debug-log. The juju status` msg should mention that the TLS configuration is being applied.
3. Wait for the charm to become active and idle
4. Verify the kubernetes Secret to confirm the new values are there

• Remove the TLS configuration

1. Remove the secret ID from the istio-pilot configuration juju config istio-pilot tls-secret-id=""
2. Remove the user secret from the model juju remove-secret istio-tls-secret
3. Observe the Gateway is not configured with TLS and the kubernetes Secret does not exist anymore

• Verify that the charm can be upgraded from 1.17/stable to the charm in this branch

TODO

• Refactor integration tests

[ca-scribner]

lgtm apart from a few minor comments

Will do another pass after the blocking PR is merged/rebased

[orfeas-k]

Really nice work @DnPlas! I left some comments

[orfeas-k]

Good job once more! Could you also include the PR's title/commit the this refers to TLS?