feat: removal of all addons

[onedr0p]

I know this PR will be greeted with mixed reviews but here's my reasons for excluding all the addons:

1. I would like to focus more on making the core bring up of talos, k0s and k3s and components more reliable and testable, having the optional addons make this tricky and very hard to test. I am basically winging it that they will work.
2. For my own sanity I would like to offload the maintenance burden of managing these applications to the person using this project, there are many nuances that I would need to keep up-to-date on (even for things I do not use personally). Additionally with the addition of k0s and talos the logic in the addons can get very spaghetti 🍝
3. There is no great way to prevent clobbering of these addons (even the core components struggle with this) when someone has made changes to their files and then reruns task configure. I would like to build out the core components in a way that makes it so they are somewhat customizable to prevent clobbering of the files. Doing that with the addons would require too much work, logic, spaghetti and testing.

With that said, in the future I can foresee a community maintained repository for addons that would compliment this repo but for now I would like to focus on testing the core distros and components and revamping the config file.

Other changes:

• This PR also moves openebs to the openebs-system namespace and renames tools ns to system-tools
• Talos kubeprism host is changed to 127.0.0.1 in the cilium config

[samip5]

SHIP IT

[joryirving]

LGTM 🚀

I 100% agree. I think addons should be community maintained, if at all. The idea of the template is to get a cluster up and running. You don't learn anything if you have the entire thing handed to you on a platter.
I don't think it makes sense to maintain things like hajimari, or homepage, or longhorn.

[onedr0p]

Maybe in the future some of the addons removed here could be added as core components (e.g. system-upgrade-controller) but for now it's better to axe them and circle back on it later with a discussion why something should be included by default.

[lltr]

LGTM 😄

[mrueg]

suggestion the namespacing: would it make sense to prefix the namespaces that are created by this template? (e.g. system-openebs and system-tools (rather than mixing prefix and postfix)

[onedr0p]

suggestion the namespacing: would it make sense to prefix the namespaces that are created by this template? (e.g. system-openebs and system-tools (rather than mixing prefix and postfix)

I'm seeing so many different opinions out there on naming it's hard to be consistent (e.g. longhorn recommends longhorn-system, volsync recommends volsync-system, then there is flux-system as well :/)

Here's my thought and it's probably wild but maybe suffix with -system for operator only namespaces and then prefix with system for grouping non operator cluster based apps.