Logically group fields in the spec

[everettraven]

This change is unrelated to either the OpenShift or Kubernetes API Conventions and is focused on ensuring that fields are logically grouped and that these logical groupings are valid as our feature set and API is expanded post-v1.0.0.

Building on #1088 , the RFC proposed a structure similar to:

type ClusterExtensionSpec struct {
 Source SourceConfig `json:"resolution"`
 Install InstallationConfig `json:"install"`
}

type InstallationConfig struct {
 Namespace string `json:"namespace"`
 ServiceAccount ServiceAccountReference `json:"serviceAccount"`
 Preflight *PreflightConfig `json:"preflight,omitempty"`
}

An example of a ClusterExtension, in YAML, with these changes (and building on top of the discriminated union changes):

apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
 name: argocd
spec:
 resolution:
 type: Catalog
 catalog:
 packageName: argocd-operator
 version: 0.6.0
 install:
 namespace: argocd
 serviceAccount:
 name: argocd-installer

Additionally, the ClusterExtension.Status should be updated to have logically grouped status information as well:

type ClusterExtensionStatus struct {
 Install *InstallStatus `json:"install,omitempty"`
 Resolution *ResolutionStatus `json:"resolution,omitempty"`

 Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"`
}

type InstallStatus struct {
 Bundle *BundleMetadata `json:"bundle,omitempty"`
}

type ResolutionStatus struct {
 Bundle *BundleMetadata `json:"bundle,omitempty"`
}

Having these distinct, logical sections in both the ClusterExtension.Spec and the ClusterExtension.Status allows for logical expansion of fields. For example, if we wanted to add the ClusterCatalog that the bundle we resolved to was from in the status, it would be a straightforward update to add a new field to the ResolutionStatus struct above.

[yashoza19]

/assign