yaml/v2: apply the namespace uniformly to the resource name

[EronWright]

There's a minor wart in how the yaml.v2 package chooses to name the child resources, in that it may or may not incorporate the namespace. It would be more consistent if the namespace were always included (for namespaced resources only, of course). The benefit is improved name stability and regularity.

The underlying reason is that the provider includes the namespace only if it is literally specified, not defaulted. It also doesn't know whether a given kind is namespaced (but could use the dynamic client to discover it).

For example, given this manifest we'd get the following stack:

kind: ConfigMap
metadata:
  name: cm1
---
kind: ConfigMap
metadata:
  name: cm2
  namespace: foo

Current stack resources (6):
    TYPE                                NAME
    pulumi:pulumi:Stack                 issue-1971-nodejs-dev
    ├─ kubernetes:yaml/v2:ConfigGroup   cg
    │  ├─ kubernetes:core/v1:ConfigMap  cg-cm1
    │  └─ kubernetes:core/v1:ConfigMap  cg-foo/cm2

I would advocate for the resultant stack to be:

Current stack resources (6):
    TYPE                                NAME
    pulumi:pulumi:Stack                 issue-1971-nodejs-dev
    ├─ kubernetes:yaml/v2:ConfigGroup   cg
    │  ├─ kubernetes:core/v1:ConfigMap  cg-default/cm1
    │  └─ kubernetes:core/v1:ConfigMap  cg-foo/cm2

There's a further complication: what if the kind is non-existent because a CRD hadn't been applied yet. In that case, one cannot determine whether the kind is namespaced and thus whether to apply the default namespace.

[EronWright]

I'm going to close this as 'won't fix' due to the complication of missing kinds. The resource name would be too volatile if it hinged on whether a CRD is registered. Note the similar logic here that is less volatile because it doesn't affect the resource identity.

See similar issue: #147

[EronWright]

I feel we need to reopen this issue, to make the implicit/explicit reordering logic work with objects in the default namespace. For example, imagine that an object has a depends-on annotation: /namespaces/default/Pod/my-pod. Imagine that the Pod spec doesn't have a namespace field because it is relying on the provider's default namespace. The namespace must be made explicit before the dependency may be realized.