[feature] Improve the "get resource" experience

[lblackstone]

Today, we provide .get methods for all Kubernetes resource types, as well as specialized getResource methods for Helm, YAML, and Kustomize components. These getters share the following limitations:

1. No retry -- If the lookup fails, then an error is returned. This doesn't play nicely with resources created by an operator, for example.
2. Unable to customize readiness check -- In some cases, the user may want to look up the current resource state without checking readiness. In other cases, it will be helpful to wait for the resource to be ready to make sure that all properties are populated. It's not currently possible to configure this behavior.
3. Inconsistent UX between resource getters and getResource methods -- It would be helpful to have a unified way to get resources, regardless of how they were created.
4. ID format is confusing to users -- We regularly get questions about how to get existing resources with our provider, so there's room to improve on the UX here.
5. No fuzzy matching -- We don't support either globbing or label-based matching, which might be useful in some cases.

Proposal

While we already provide getters for every resource type in Kubernetes, it may be helpful to create a higher level "porcelain" getter to address the mentioned limitations. This might look something like this:

function GetResource(groupVersion: string, kind: string, name: string, namespace?: string, getOpts): pulumi.CustomResource {
// getOpts include parameters to configure retry and await behavior
}

Related issues:

#1177
#1238
#264
#305
#1673

[mikhailshilkov]

We should consider if/how this applies to other providers too.

[akath19]

End user here, I've been using this for a while and I'd love to see the following features:

• Globbing for names: Resource names sometimes are not fully known e.g: service-account-token-? or deployment-name-?, however, the root of the name e.g.: service-account-token, deployment-name is always known
• ObjectState for metadata: Instead of having to craft a specialized ID or name, using ObjectState for the named object e.g.: SecretState, PodState and including required metadata there might make it easier and more aligned with creation patterns
• Piping: Being able to accept get results as references for resource creation, a common pattern is searching for an object and using the object name or contents to create new objects