Enhancement proposal to provide cluster configuration options that
disable the generation of the `builder` service account. Today,
OCP generates the `builder` service account in every namespace for
clusters that enable the "Build" capability. Long-living clusters
that upgraded from OCP 4.13 or earlier are not able to turn off the
"Build" capability, but may have otherwise found ways to disable
builds on OCP through RBAC controls. In these instances, the
`builder` service account represents a potential security threat,
which cannot be mitigated without overrides that bring the cluster
into an unsupported state.

Turning off the `builder` service account will have significant
impact on developer experience, which can be mitigated through
accurate documentation and the use of internal developer platforms
like RHDH (powered by Backstage). The proposal outlines these
requirements as well as requiring builds to "fail fast" if the
referenced or implied service account does not exist.

Signed-off-by: Adam Kaplan <adam.kaplan@redhat.com>

Typo in "configuring"

Co-authored-by: Maciej Szulik <soltysh@gmail.com>

- Add context around long-lived cluster upgrading to OCP 4.14,
  particularly for large fleets.
- Add details related to SLI metrics for builds. The current metrics
  for BuildConfig do not provide reliable, long-running data.
  Addressing this is out of scope.
- Add requirement that we verify builds can succeed if admins/platform
  teams bring their own service account for builds.

Use runtime validation by the ocm-o cluster operator to handle
defaulting of the new `spec.builderServiceAccount` field. This allows
us flexibility to change the default behavior of OCP in the future.
There is a minor cost to implementing this in the operator, instead of
CRD defaulting mechanisms.

The proposal was also updated to use the new enhancement template.

Document that OpenShift already has mitigations in place for this
feature for large clusters. Openshift-controller-manager already has
QPS limits for each individual controller (10 QPS), which implies an
upper bound of 40 objects created per second (each reconcile can create
a service account, role binding, and 2 Secrets for internal registry
auth tokens). At scale, this contributes small amounts of storage
(40 MiB max per 10k namespaces) and will not flood the cluster with
object creation.

Final copy edit of the enhancement proposal.