Rename ConfigSource and Source to RefSource

Recently, we introduced a new field named provenance in TaskRun/PipelineRun CRD
status, and one of its subfields is named `ConfigSource`. Meanwhile, we introduced
`source` field into `ResolutionRequest` CRD status to pipe the value.

In this commit, we renamed both `configSource` and `source` to `RefSource`.

Reasoning: ConfigSource is the SLSA name and ties to a specific SLSA version.
It also makes this a leaky abstraction, i.e. we are naming fields in our API
after how we want to use them. Additionally, `config` isn't a concept that
exists in Tekton. Also the name `source` is too generic.

Backward compatibility: This PR doesn't remove the old field. Instead, it
keeps the old field while introducing the new name to give a release of warning.
The old name will be removed in future release for a smooth transition.

Signed-off-by: Chuang Wang <chuangw@google.com>

docs/bundle-resolver.md

@@ -89,7 +89,7 @@ spec:
 ```
 
 ## `ResolutionRequest` Status
-`ResolutionRequest.Status.Source` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
+`ResolutionRequest.Status.RefSource` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
 - `uri`: The image repository URI
 - `digest`: The map of the algorithm portion -> the hex encoded portion of the image digest.
 - `entrypoint`: The resource name in the OCI bundle image.
@@ -148,7 +148,7 @@ status:
   ...
   data: xxx
   observedGeneration: 1
-  source:
+  refSource:
     digest:
       sha256: f51ca50f1c065acba8290ef14adec8461915ecc5f70a8eb26190c6e8e0ededaf
     entryPoint: git-clone

docs/cluster-resolver.md

@@ -82,7 +82,7 @@ spec:
 ```
 
 ## `ResolutionRequest` Status
-`ResolutionRequest.Status.Source` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
+`ResolutionRequest.Status.RefSource` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
 - `url`: url is the unique full identifier for the resource in the cluster. It is in the format of `<resource uri>@<uid>`. Resource URI part is the namespace-scoped uri i.e. `/apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME`. See [K8s Resource URIs](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) for more details.
 - `digest`: hex-encoded sha256 checksum of the content in the in-cluster resource's spec field. The reason why it's the checksum of the spec content rather than the whole object is because the metadata of in-cluster resources might be modified i.e. annotations. Therefore, the checksum of the spec content should be sufficient for source verifiers to verify if things have been changed maliciously even though the metadata is modified with good intentions.
 - `entrypoint`: ***empty*** because the path information is already available in the url field.
@@ -130,7 +130,7 @@ status:
   annotations: ...
   conditions: ...
   data: xxx
-  source:
+  refSource:
     digest:
       sha256: 245b1aa918434cc8195b4d4d026f2e43df09199e2ed31d4dfd9c2cbea1c7ce54
     uri: /apis/tekton.dev/v1beta1/namespaces/default/task/a-simple-task@3b82d8c4-f89e-47ea-a49d-3be0dca4c038

docs/git-resolver.md

@@ -155,7 +155,7 @@ spec:
 ```
 
 ## `ResolutionRequest` Status
-`ResolutionRequest.Status.Source` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
+`ResolutionRequest.Status.RefSource` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
 - `url`
   - If users choose to use anonymous cloning, the url is just user-provided value for the `url` param in the [SPDX download format](https://spdx.github.io/spdx-spec/package-information/#77-package-download-location-field). 
   - If scm api is used, it would be the clone URL of the repo fetched from scm repository service in the [SPDX download format](https://spdx.github.io/spdx-spec/package-information/#77-package-download-location-field). 
@@ -195,7 +195,7 @@ spec:
     revision: main
     url: https://github.com/<username>/<reponame>.git
 status:
-  source:
+  refSource:
     uri: git+https://github.com/<username>/<reponame>.git
     digest:
       sha1: <The latest commit sha on main at the moment of resolving>

docs/how-to-write-a-resolver.md

@@ -267,23 +267,23 @@ func (*myResolvedResource) Annotations() map[string]string {
   return nil
 }
 
-// Source is the source reference of the remote data that records where the remote 
+// RefSource is the source reference of the remote data that records where the remote 
 // file came from including the url, digest and the entrypoint. None atm.
-func (*myResolvedResource) Source() *pipelinev1beta1.ConfigSource {
+func (*myResolvedResource) RefSource() *pipelinev1beta1.RefSource {
 	return nil
 }
 ```
 
 Best practice: In order to enable Tekton Chains to record the source 
 information of the remote data in the SLSA provenance, the resolver should 
-implement the `Source()` method to return a correct ConfigSource value. See the 
+implement the `RefSource()` method to return a correct RefSource value. See the 
 following example.
 
 ```go
-// Source is the source reference of the remote data that records where the remote 
+// RefSource is the source reference of the remote data that records where the remote 
 // file came from including the url, digest and the entrypoint.
-func (*myResolvedResource) Source() *pipelinev1beta1.ConfigSource {
-	return &v1alpha1.ConfigSource{
+func (*myResolvedResource) RefSource() *pipelinev1beta1.RefSource {
+	return &v1alpha1.RefSource{
 		URI: "https://github.com/user/example",
 		Digest: map[string]string{
 			"sha1": "example",