build: Build controller handling of service account can lead to failing build runs and other artifacts

In a build run spec, there is a section about the service account. This section can be

1. set to a specific name and generate = false to make use of the specified service account
2. set to generate = true to generate a service account specific to the build run
3. omitted to get the default behavior which is to use the pipeline service account or - if that does not exist - the default service account

When the generated service account is not used, our logic in generate task run will add the secrets referenced in the build (for example for the source repository and the target container registry) to the specified service account if the secret is not already contained.

If the user now deletes one of those secrets, the service account is broken and our controller will also not repair it. If the user now tries to create a build run that uses such a service account, then the build run will fail with this reason: failed to create task run pod "new-build-run-kwkl5-j9b27": translating TaskSpec to Pod: secrets "something" not found. Maybe invalid TaskSpec As a service account can be used for other means as well (especially if scenario 3 applies and a fallback to default happens), those other things might also fail (job, deployment) (I should mention that I did not try how they behave with such a service account).

Here are some options that I see:

(A) Watch secret deletions and remove references from the service account(s). This would probably be possible if we would only support either a hard-coded service account or a generated one. But given the user can use a named service account for his build runs, this could mean that we need to manage a lot service accounts.

(B) At the time we assign a named service account to a build run, we check whether all secrets really exist and if one does not exist we fail the build run with an error message that is nicer than the one coming from Tekton.

© At the time we assign a named service account to a build run, we check whether all secrets really exist and if one does not exist we remove it from the service account.

(D) We do nothing and only document the current behavior.

In addition to those options, we may also consider a configuration setting for the controller that allows to force a build run to use a generated service account by ignoring the intent of the user specified in the build run.