Ensure pullrequest-init is based on a root image

[ghost]

fixes #3054

Changes

The PullRequest Resource, when used as an output, is able to
read in a pr.json to determine if there have been any changes
that require syncing to github. pr.json may have been written
by any prior Step with any ownership settings. If pr.json
was written with root permissions then the PullRequest Resource
needs to be have permissions to read that file.

The PullRequest Resource image has been based on a nonroot
image in our .ko.yaml since 0.13 of Tekton Pipelines (.ko.yaml was
updated here).

However, the published images did not match the configuration in the
.ko.yaml until 0.15.0 (our tekton/publish.yaml was brought into line
with .ko.yaml here).

Given that copying or writing pr.json in a Step can result in the file
being owned by root using a nonroot image is not a suitable choice
of base image - the output PullRequest attempts to open pr.json and
hits a permissions error.

This commit updates the PullRequest image to be based on
distroless static instead of nonroot and adds an example yaml
file that should exercise the behaviour of copying the file from
an input to output pullrequest resource.

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)
• Commit messages follow commit message best practices
• Release notes block has been filled in or deleted (only if no user facing changes)

Release Notes

Fix an issue where an output pullrequest resource could fail because a pr.json file was written by a Step with root ownership.

[ghost]

/kind bug

[dlorenc]

However, the published images did not match the configuration in the
.ko.yaml until 0.15.0 (our tekton/publish.yaml was brought into line with .ko.yaml here).

Ohhhh! Nice debugging.

[dlorenc]

/lgtm

[bobcatfish]

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bobcatfish

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 [bobcatfish]

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

[bobcatfish]

is it true that this would apply to any container that needs to operate on any file written by a previous step? if so this feels like it might be a slightly larger problem since it feels like communicating b/w steps is a big part of our design 🤔 (maybe im over exaggerating that?)

[ghost]

Yeah, I do think that's a risk we might want to spend a bit more time analysing. Here I'm fixing the immediate issue we observed in dogfooding wrt the PR pipeline resource.