Support for kustomize vars/replacements source logic in postBuild

[aclerici38]

I have a lot of flux kustomizations with the same entries in postBuild.substitute, like so

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: appname
spec:
  ...
  postBuild:
    substitute:
      APP: appname

I could use kustomize replacements (or deprecated vars) to somewhat standardize adding this but both only accept a single source, so that would require a kubernetes kustomization for each flux kustomization which is not how my repo is structured.

I believe a good solution is for postBuild to support the same source-from-a-built-resource logic kustomize uses. The example above would become something like

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: appname
spec:
  ...
  postBuild:
    substituteFrom:
      - kind: resource
        var: APP
        source: 
          kind: Kustomization
          fieldPath: metadata.name

And could obviously be extended to other resources built by the flux kustomization

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: appname
spec:
  ...
  postBuild:
    substituteFrom:
      - kind: resource
         var: NS
         source: 
           kind: Namespace
           fieldPath: metadata.name

This could easily be patched in, preventing the repetitive stanzas.
Using postBuild's var substiturion here would also work around an issue with replacements when there is no common delimiter kubernetes-sigs/kustomize#5616.

Caveats I can think of:

• In my first example the source and destination resource is the flux kustomization itself. I'm not sure if this is possible, my gut says no, but I figured I'd ask. I'd be happy to amend this to just the general postBuild source -> var logic, self-sourcing excluded.
• I've seen other postBuild proposals closed for bordering on templating, I can see how this would be similar. In my opinion, however, this is much more of an enhancement to work around a kustomize limitation
• This is virtually the same behavior as kustomize vars. However, with vars being deprecated I think it's important to maintain the functionality currently lacking in kustomize replacements

Thanks!