Expose author information about packagerevisions through the API

[mortent]

Currently Porch doesn't expose any information about audit information about edits and approvals of packagerevisions through the API. We should capture who edited/proposed/approved a packagerevision and when it happened and expose it as part of the packagerevision API.

The data needs to be captured when it happens, so it must be included in the commit information. Commits do have timestamps so we can leverage those for determining when something happened. In order to keep track of who did something, we need to either make commits on behalf of someone (is using the email address in the commit enough?) or include it in the commit message itself. I think we can leverage the UserInfoProvider for this.

[mortent]

So Porch already captures the author of each task (i.e. commit) in git. Porch gets this information from the kubernetes apiserver, so the author of each commit will be set to the current user in kubernetes. Porch sets itself as the committer.

This information is currently not surfaced through the API. We have a couple of options of how we can do it:

1. Arguably it is not all that interesting to look at the author of every single change to a draft package revision, but we do want to surface the author and timing of the keep events in the lifecycle of a package revision. The key event here is when the package revision is published. We can add approvedBy and approvedTimestamp fields to the packagerevision resource. These would be empty until the package is published. We could add similar fields to for creation of a packagerevision, but unclear if that is useful. This is a simpler solution that exposing author and timestamp for every change to a package.

2. We can add additional fields to the task struct to include the author and timestamp for each task. As mentioned above, we already do capture this information as part of the git commits, although the timestamps are reset whenever a package is approved, since it involves recreating the commits on the main branch (not sure if there is a way in git to move the commits without updating the timestamps). Adding these fields to the task struct used in the the spec doesn't feel quite right, as it can't be set by the clients, but it set by the server as a result of running the tasks.

3. We can provide author and timestamp information for each task through the status object of the packagerevision resource. It would mean creating a taskStatuses list containing taskStatus entries. These would have author and timestamp fields that will be set by the apiserver based on the information from git/oci. The taskStatuses would mirror the order from the task list in the spec. This approach does create a better separation between the fields that can be set by the client and the ones that are determined by the apiserver. However, the two mirrored lists which requires clients to match entries based on their index feels awkward.

Since approvals are not captured as a task in each packagerevision, we probably need option 1 regardless. I suggest we punt on implementing 2/3 until we know whether this is information that are actually useful to users. Open to input on this.

@justinsb @johnbelamaric