Initial proposal: #1309

Context

Per Amazon's design, users must create one IAM Role and one Trust Relationship per Service Account (hence, per source instance). This is quite a tedious process, and for some people it is just fine to use a shared serviceAccount for selected sources.

The original PR was not merged because the solution there was based on the k8s object annotations which is not a common approach for this kind of modification in our components.
An additional requirement: provided service account may already exist; in this case, we should not reconcile it to avoid conflicts.

Proposed change

This PR introduces the following AWS Auth spec update (for all AWS components):

• Deprecate spec.auth.iamRole parameter - all creation requests for AWS components with this attribute in their spec will be rejected by the webhook (and CRD requirements). Existing objects will continue their work,
• Introduce a new spec.auth.iam object with roleArn and serviceAccount attributes to replace and extend the deprecated iamRole parameter. roleArn expects the value that was previously set in iamRole parameter, and serviceAccount is the Kubernetes service account name to create or re-use for the adapter deployment. At least one of the attributes must be present in the spec.auth.iam object.

Example

AWS Auth spec before:

apiVersion: sources.triggermesh.io/v1alpha1
kind: <AWS source>
metadata:
  name: foo
spec:
  arn: <resource ARN>

  auth:
    iamRole: arn:aws:iam::123456789012:role/dev-role

-service account with a preconfigured name will be created for the source by the controller.

Some options after this PR:

apiVersion: sources.triggermesh.io/v1alpha1
kind: <AWS source>
metadata:
  name: foo
spec:
  arn: <resource ARN>

  auth:
    iam:
      roleArn: arn:aws:iam::123456789012:role/dev-role

-spec format update with no behavior change - SA with the preconfigured name will be created by the controller.

apiVersion: sources.triggermesh.io/v1alpha1
kind: <AWS source>
metadata:
  name: foo
spec:
  arn: <resource ARN>

  auth:
    iam:
      roleArn: arn:aws:iam::123456789012:role/dev-role
      serviceAccount: aws-source-sa

-service account aws-source-sa will be created by the controller. If a service account with this name already exists, the controller checks the labels, and, if the label managed-by has the value triggermesh-controller, SA's owners list is updated with the current object. If the label managed-by does not exist or it has a value different from triggermesh-controller, reconciliation is skipped. Then this SA is assigned to the adapter deployment.
SA's annotation "eks.amazonaws.com/role-arn" can be overwritten by the controller only if SA is managed by the triggermesh controller and there is only one owner to it, otherwise, annotation is ignored to avoid reconciliation conflicts.

apiVersion: sources.triggermesh.io/v1alpha1
kind: <AWS source>
metadata:
  name: foo
spec:
  arn: <resource ARN>

  auth:
    iam:
      serviceAccount: aws-source-sa

-service account aws-source-sa will be created if needed and assigned to the receive adapter deployment. If the service account did not exist before, it will be created without the IAM role annotation (spec.auth.iam.roleArn is not defined) and the source will fail to authenticate against the AWS API.

Bonus 1:
Since this PR updates common reconciliation logic for Kubernetes service accounts, this also affects the GCP components. Custom KSA name support added in #1372 can now be utilized as shared and externally created service account support in GCP sources and targets.

Bonus 2:
This PR introduces a new Make target - codegen-cleanup. In dev environments where the triggermesh project is located outside the GOPATH, make codegen could result in a github.com directory created in the project's root with all the generated files in it. While I failed to find the proper configuration fix for the k8s code generators, make codegen-cleanup can fix the resulting directory tree.