potential issue with TLS configuration and system certificates

in the testing and staging envs we usually deal with, we need a self-signed certs operator to enable e2e TLS in our charmed deployments.
In real deployments, however, one may have their ingress certs be signed by an actual CA and therefore the system certs will be enough to validate the signatures.

In #133 we configured the workers/coordinators to block in case we receive an https endpoint from the ingress, but we ourselves don't have a certificates relation.
The charms at the moment don't have logic to verify whether this situation is intentional (because the user wants the coordinated workers to use system certs) or a mistake, and we set blocked.

We may need a more sophisticated way to verify the configuration instead.
A possible solution would be:
when the ingress hands us an endpoint, attempt to curl it with a cert if we have one, else without (thereby using the system certs). If that fails, then we know there is a misconfiguration.

Start by tracing the HTTPS endpoint handling introduced in issue #133 and inspect how ingress endpoints, system certificates, and the certificates relation are represented in the charms. Done means distinguishing intentional CA-signed ingress, which should not be blocked, from a certificate misconfiguration that should remain blocked; the issue does not name specific files or tests.

Written by the indexing model from the issue text.