Secure the ksvc, QP prometheus endpoints etc

## Describe the feature
Serving exposes prometheus metrics in the control plane for ksvcs ( via autoscaler and controller svc), and uses functionality from pkg [metrics](https://github.com/knative/pkg/blob/62f2560aa795d29ab6300641bc69540c69bdf98b/metrics/prometheus_exporter.go#L44) in order to create a prometheus exporter, that listens to a specific path/port by default. This is not protected in any way.
This is problematic for multi-tenant users as any pod can hit a svc in the same cluster and leak information about ksvcs running on cluster by listing the related metrics.
In general this affects all prometheus endpoints.

Some solutions:
a) when serving mesh is used use the provided capabilities for example for istio we can have both [encryption and basic auth](For mutual tls plus token auth (more complex) we could use what the mesh provides for example:
https://istio.io/latest/docs/tasks/security/authentication/authn-policy/#globally-enabling-istio-mutual-tls-in-strict-mode
https://istio.io/latest/blog/2020/proxy-cert/).

b) use a proxy as a side car to manage access, for example [kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy/tree/master/examples/non-resource-url)

/cc @vagababov @markusthoemmes @nak3 (credit to @nak3 who initially reported this). WDYT?