fix: zarf optional component negation

[rjferguson21]

Description

...

Related Issue

Fixes #

Relates to #

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps(https://github.com/defenseunicorns/uds-template-capability/blob/main/CONTRIBUTING.md#submitting-a-pull-request) followed

[UncleGedd]

Chatted with @zachariahmiller to get more context on this. @rjferguson21 would you like to implement the overrides.<component>.enabled syntax? (no pressure!)

[UncleGedd]

Context so I don't forget again: the team is requesting the ability to override the required key of a Zarf pkg component. In other words, regardless of whether a component is required in a zarf.yaml, bundle authors have the ability to enable a component during bundle creation

[rjferguson21]

@UncleGedd I'd love to try to implement that.

I believe the there are technically two pieces.

• prevent a particular zarf component that is required: false, default: true, from deploying at bundle deploy time.
• prevent the same component from being included in the bundle at create time

I think it would be reasonable to do the first bullet, and tackle the second at a later date. /cc @zachariahmiller

[UncleGedd]

That sounds good, I like the idea of breaking the issue up into smaller chunks. What do you think of this syntax:

kind: UDSBundle
metadata:
  name: foo
  version: 0.0.1

packages:
  - name: podinfo
    repository: ghcr.io/defenseunicorns/uds-cli/podinfo
    ref: 0.0.1
    overrides:
      metrics-server:
        enabled: false

[UncleGedd]

Hey @rjferguson21 looks like Zarf is refactoring required vs optional key on their side. I recommend waiting until that behavior is finalized before implementing this