Support GitOps-y installation of Iter8

[sriumcp]

Is your feature request related to a problem? Please describe the problem.
Iter8's builtin metrics rely on this installation step currently ...

kustomize build https://github.com/iter8-tools/iter8/install/builtin-metrics/?ref=${TAG} | kubectl apply -f -

This requires metric CRDs to be registered in advanced, not just applied (otherwise, this step will fail). CRD registration is currently verified as follows ...

kubectl wait crd -l creator=iter8 --for condition=established --timeout=120s

A shell command like the above precludes the installation of Iter8 by GitOps-operators like ArgoCD. Without this shell command, ArgoCD can deploy Iter8 directly using Iter8's kustomize folder today, and Helm chart in the future (when #909 is implemented).

Describe the feature/solution you'd like

1. Reserve iter8-system/mean-latency (and other such built-in metric names) for Iter8 usage.
2. Require all references to built-in metrics to use these fully qualified (namespaced-)names.
3. Change etc3 so that it uses go constants for fetching built-in metrics. When built-in metrics need to be populated in status.metrics slice, etc3 will use these constants, instead of querying the K8s API Server.

Will this feature/solution bring new benefits for Iter8 users? What are they?
Enable Iter8 to be installed using a GitOps operator like ArgoCD.
Simplify both Kustomize and Helm installation (in particular, current Kustomize install will become a single line command, followed by a pod-verification kubectl command; this pod verification command is not needed for gitops install -- the operator does this automatically).

Does this issue require a design doc/discussion? If there is a link to the design document/discussions, please provide it below.
Yes, please see above.

How will this feature be tested?

• env tested in etc3. e2e tested in iter8 tutorials.

How will this feature be documented?

• Reflect these changes in built-in metrics documentation.

[sriumcp]

Subsumed by #934