WIP: add support for Oberve Only resources

[yardbirdsax]

Description of your changes

This is a work in progress; I'm just opening this in draft mode to signal intent in case other folks were thinking of the same thing (and to get early feedback if anyone wants to 😄 ). Once I finish the implementation, I'll mark it ready for review.

This adds the new ManagementPolicy field to the Workflow resource by updating the crossplane/crossplane-runtime module to the latest master commit. It also resolves a dependency conflict when the API types or other packages from this module are imported simultaneously as ones from other providers, such as upbound/provider-aws since those use the newer crossplane-runtime versions already. Related dependencies have also been updated. I also updated the version of golangci-lint; the older version (1.50.0) has some known performance issues that this resolves (see the various comments on golangci/golangci-lint#3414).

I have:

• Run make reviewable to ensure this PR is ready for review.

How has this code been tested

I ran the existing unit tests which all passed. I may try and add some new ones as part of finishing the implementation. When running the end-to-end tests (make e2e) it fails with the error uptest-v0.5.0: error: No manifest to test provided.; I confirmed this is also true on the main head, so it seems to be an existing problem.

[Upbound-CLA]

All committers have signed the CLA.

[ytsarev]

@yardbirdsax that is interesting. How do you envision Observe Only resources working in combination with provider-terraform Workspace? What is the desired result if we compare with the execution of standard terraform data source as in the following example https://github.com/upbound/provider-terraform/tree/main/examples/observe-only-composition ?

[yardbirdsax]

Good questions!

How do you envision Observe Only resources working in combination with provider-terraform Workspace?

I would imagine this (setting managementPolicy: Observe, or managementPolicy: [Observe] in the newly proposed model) would mean that the Provider would essentially only run terraform init and terraform plan, but not terraform apply. This would allow someone to, say, point Crossplane and the Provider at an existing state file and set of Terraform code, and leverage functionality like transposing Terraform outputs into secrets, without necessitating going all in on having Crossplane and the Provider reconcile the state of the resources itself. It might also allow us to detect drift in resources, while not automatically correcting them. (The latter is very similar to what's described with the Weaveworks Flux Terraform Controller [here](https://docs.gitops.weave.works/docs/terraform/Using Terraform CRD/drift-detection/).)

What is the desired result if we compare with the execution of standard terraform data source as in the following example?

In that case, at least if the intent is similar to how I've typically seen datasources used, we're trying to observe something created by something else, and use attributes of that thing in defining another resource that we are creating and managing. Sort of like a lookup, versus "I want you to watch this thing and report on its status and if it matches how we want it to, but don't actually change it."

[yardbirdsax]

Based on comments in the Crossplane Slack channel, I’m moving this back to draft mode until the new style (I.e., array vs single value) managementPolicy field is implemented upstream in the Crossplane runtime (supposedly next release).

[ytsarev]

@yardbirdsax thanks a lot for the clarification, makes total sense, let's try it out. I will be happy to test it e2e when we get to the final implementation.

[ytsarev]

@yardbirdsax #195 should implement this. I will close this PR, feel free to reopen if needed 👍