Stacks and Workloads should use bespoke status conditions

[negz]

What happened?

When installing the GCP stack I went to inspect its status and noticed that its conditions state the "managed resource" is being created, and has successfully been reconciled. "Managed resource" in Crossplane parlance typically means "Crossplane resource that represents an external resource", typically in a cloud provider - RDSInstance is a "managed resource" because it represents an AWS RDS instance. MySQLInstance (a resource claim), KubernetesApplication, and StackRequest are not managed resources.

$ kubectl -n gcp describe stackrequest
Name:         stack-gcp
Namespace:    gcp
API Version:  stacks.crossplane.io/v1alpha1
Kind:         StackRequest
Spec:
  Package:  build-1be35bec/stack-gcp-amd64:latest
Status:
  Conditioned Status:
    Conditions:
      Last Transition Time:  2019-09-13T02:49:24Z
      Reason:                Managed resource is being created
      Status:                False
      Type:                  Ready
      Last Transition Time:  2019-09-13T02:49:24Z
      Reason:                Successfully reconciled managed resource
      Status:                True
      Type:                  Synced
  Install Job:
    Name:       stack-gcp
    Namespace:  gcp
Events:         <none>

crossplane-runtime exposes a handful of frequently used conditions, including Available, Deleting, and ReconcileError, but is otherwise unopinionated about what conditions a resource supports. The aforementioned frequently used conditions all mention "managed resources" because that wording makes sense in the context of reconciling a managed resource claim or resource claim. It does not make sense for a stack or a workload; Stacks and Workloads should define their own variants of these conditions with contextually appropriate "reason" messages.

How can we reproduce it?

What environment did it happen in?

Crossplane version:

[negz]

@muvaf did a little related work in crossplane/crossplane-runtime#99, in that we no longer say "managed resource", but rather just "resource". Despite this I think there could still be value in using bespoke conditions.

[negz]

In retrospect, I think the work per the previous comment is enough that we don't need an issue tracking this.