Migrate to a pattern of having one reference deployment per git repository

[RothAndrew]

Now that the on-prem-lite reference deployment is in a good spot, we're looking at starting the next one. This is bringing up some issues that may be tricky to solve in a monorepo:

1. If I make a change that only affects one of the deployments, I shouldn't have to run the tests for the other deployment in order to get the change merged to main
2. When I copy/paste the repo to bootstrap a real deployment, a monorepo of other deployment models means I need to go delete a bunch of stuff that isn't relevant to me

But, having multiple repos also has cons:

1. Harder to maintain
2. Harder to keep changes in sync

Mitigations to those cons could be:

1. Use the pattern that @zack-is-cool is starting to establish by using git-xargs to centrally maintain content that is the same across all repos
2. Use reusable github actions pipeline workflows
3. Keep using our established pattern of Renovate and Release-Please

Proposed solution:

1. Rename this repo to defenseunicorns/narwhal-delivery-reference-deployment-on-prem-lite (phew, that's a long one...)
2. Make a repo called defenseunicorns/narwhal-delivery-reference-deployment-central-config that lets us make changes to common files in one spot
3. Wire up the on-prem-lite repo to be managed by the central-config repo
4. Make a new repo called defenseunicorns/narwhal-delivery-reference-deployment-<TheNextDeploymentWeDo>
5. Wire up that repo to the central-config repo
6. profit 💰

[ntwkninja]

my first thought is repo-ception 🤯

Could we leverage the existing make pattern or pull in zarf / pepr to do logic more natively within our tools?

make.infra or aws zarf package (i.e. infra dependencies for aws, on-prem/ec2-sim)
make.cluster or k8s zarf package (i.e. aws/eks, aws/rke2, aws/k3d, etc.)
make.platform (really just zarf package dubbd)
make.mission-app (example app that needs depdencies satisfied by a combination of the previous things)

[RothAndrew]

yes. we can do that. The existing pattern of targets in the makefile mostly does that now, and would continue to do so. The question at hand is whether to continue with the monorepo approach or split out each reference deployment into its own repo.

[ntwkninja]

My vote presently would be to keep it as an up-to-date reference(s) vs. as a supported product in of itself; mainly because I expect a lot of upstream changes in the next 3 months. Approach the topic again in Jan?

edit: add up-to-date to describe the type of reference