User-defined await logic

[blampe]

This adds implementations for user-defined await logic.

Two styles are supported, both equivalent to kubectl:

• condition=Type[=Value]
• jsonpath={expr}[=Value]

The user can specify these via annotations, e.g.:

• pulumi.com/waitFor: condition=Foo
• pulumi.com/waitFor: jsonpath={.webhooks[0].clientConfig.caBundle}

kubectl --wait for=jsonpath= supports a more relaxed syntax than kubectl get -o jsonpath= which I found to be somewhat buggy/surprising in how it parsed
expressions, so for now we only support the stricter get syntax.

Some code related to evaluating custom conditions is vendored from kubectl to
stay as close as possible to upstream behavior.

We use the same k8s.io/client-go/util/jsonpath library used by kubectl for
evaluating JSONPath expressions.

An E2E test is included which shows how this feature allows cert-manager to be
successfully deployed after applying two waitFor annotations. (Something we
would eventually want baked in to pulumi-kubernetes-cert-manager.)

Fixes #1260.
Refs #2824.

[blampe]

This change is part of the following stack:

• Unify await logic for deletes #3133
  • Add generic await logic #3143
    • User-defined await logic #3134 ◀

_{Change managed by git-spice.}

[github-actions]

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

[codecov]

Codecov Report

Attention: Patch coverage is 85.10638% with 28 lines in your changes missing coverage. Please review.

Project coverage is 39.08%. Comparing base (a8234db) to head (41bd8fe).
Report is 1 commits behind head on master.

Files	Patch %	Lines
provider/pkg/await/condition/all.go	64.28%	6 Missing and 4 partials ⚠️
provider/pkg/metadata/overrides.go	81.25%	3 Missing and 3 partials ⚠️
provider/pkg/await/condition/custom.go	80.95%	4 Missing ⚠️
provider/pkg/await/condition/jsonpath.go	86.20%	4 Missing ⚠️
provider/pkg/await/condition/kubectl.go	94.44%	1 Missing and 1 partial ⚠️
provider/pkg/jsonpath/jsonpath.go	95.23%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3134      +/-   ##
==========================================
+ Coverage   38.15%   39.08%   +0.92%     
==========================================
  Files          77       82       +5     
  Lines        9395     9580     +185     
==========================================
+ Hits         3585     3744     +159     
- Misses       5461     5478      +17     
- Partials      349      358       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[EronWright]

Do you mean any non-empty value? Would an empty string be considered a value?

[rquitales]

From the code, it looks like an empty string as a value would also be considered ready since it always returns true if the path exists.

// Matches returns true if the JSONPath matches against the given object. If
// the JSONPath didn't include a value, then this will return true if the path
// exists. Otherwise, the path must exist and hold a value equal to the
// Instance's expected value.

@blampe Can we add an additional test case to provider/pkg/await/condition/jsonpath_test.go to confirm/clarify this behaviour?

[blampe]

@rquitales for sure! FWIW this is based on https://github.com/kubernetes/kubectl/blob/c4be63c54b7188502c1a63bb884a0b05fac51ebd/pkg/cmd/wait/json.go#L72-L91 which succeeds if the path exists with any value.

[rquitales]

From the code, it looks like an empty string as a value would also be considered ready since it always returns true if the path exists.

// Matches returns true if the JSONPath matches against the given object. If
// the JSONPath didn't include a value, then this will return true if the path
// exists. Otherwise, the path must exist and hold a value equal to the
// Instance's expected value.

@blampe Can we add an additional test case to provider/pkg/await/condition/jsonpath_test.go to confirm/clarify this behaviour?