Revert "dibyo's point about only EL sink/interceptors reading secrets"

[dibyom]

Changes

This reverts commit 8eb2067.

Turns out, the webhook does need access to create secrets since it uses it
to create tekton-webhook-certs if it does not exist.

Fixes #803

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices
• Release notes block has been filled in or deleted (only if no user facing changes)

See the contribution guide for more details.

Release Notes

NONE

/kind bug

[dibyom]

Still surprised that our e2e tests passed with this...but verified manually on a fresh cluster that his patch fixes #803

[khrm]

/lgtm

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: khrm

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [khrm]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[gabemontero]

Finally got a second to look at this for a sec ... am I correct in that the knative webhook stuff is what is actually creating the secret @dibyom?

If so, perhaps because of that there is some precedence that we cannot overcome at this time (i.e. knative has mutiple places where it creates secrets dynamically), but a possible counter argument to adding secret creation back would be that we should be creating this secret as part of the resources applied from the config directory.

thoughts?