Is your feature request related to a problem? Please describe.

When a user wants to use zarf and adopt existing resources it is likely the case in packages that are not extremely simple that they will want to only adopt a subset of the components in the package, like within a specific chart in a given component. Rather than just the all or nothing --adopt-existing-resources flag, zarf should facilitate a means to adopt resources with more granularity.

Additionally, this behavior should be able to be extended into the registry chart in the zarf init package. In this case, the behavior is needed for interacting with certain development distributions where a local registry might be provided to the cluster at creation time via the local-registry-hosting ConfigMap in kube-public that zarf also uses for it's registry access config.

Describe the behavior you'd like

• Given a cluster deployed with existing resources that a zarf package will also deploy
• When an package author marks a specific chart as needing to adopt resources or to be able to adopt resources if set on deploy
• Then zarf will, dependent on the value of that setting at deploy time adopt only the subset of resources defined in the zarf package's chart component configured with adoptExistingResources

Describe alternatives you've considered

For the zarf init use case, most of the alternatives that seemed possible, like deleting the configmap before init or overwriting the metadata in an action in a shim package before init seem fragile and less than ideal, but they were considered. Alternatively in the init example, zarf init can be run by itself and adopt all resources via the CLI, but that only works for this specific use-case and requires running more commands to fully deploy to a cluster.

Additional context

A simple example of this is trying to use k3d with podman where a registry needs to be initialized for k3d to start successfully and then zarf init fails due to missing ownership references. In reality, during zarf init, zarf can take ownership of this file, provide its registry and subsequent actions on the cluster can proceed as expected in the zarf-inited cluster.