Consider removing uds.dev domain/certs by default in UDS Core

[docandrew]

Describe what should be investigated or refactored

A deployment of UDS Core will use default TLS certificates as they are baked into the Core Zarf package. These are publicly available in GitHub and should be considered compromised. This is done for convenience of development and test but leads to bad habits and can end up in production use.

I want to be confident that a production build never uses an insecure (leaked) uds.dev cert.

I would prefer to have to opt-in to a specific domain and keypair and set these values at deploy-time, since this will most closely mimic production use for delivery engineers. Explicit opt-in to a development keypair/domain is OK for local testing.

The "Getting Started" page and any guidance for Delivery engineers should consider emphasis on using a custom domain and keypair rather than the default development guidance.

Consider publishing the UDS Core "slim dev" package completely separate, so that no default certificates are in the Core Zarf package at all, but developers can continue to opt in to the current behavior for convenience.

This can cause issues with tools like TruffleHog, etc. where these private keys are exposed as well, this can lead to alarm fatigue and encourages bad habits for ignoring certain secrets in Git because "this one's OK". The presence of this key could lead to certificate revocation from the CA as well if they are aware of the key on GitHub.

Links to any relevant code

Our uds.dev key is exposed here:

https://github.com/defenseunicorns/uds-core/blob/main/src/istio/values/config-tenant.yaml
https://github.com/defenseunicorns/uds-core/blob/main/src/istio/values/config-admin.yaml