[deckhouse-cli] Better enable/disable status reporting

[Glitchy-Sheep]

The problem

Issues with d8 system module enable/disable:

1. enable on an already-enabled module silently succeeds (no warning)
2. enable after disable fails for experimental modules if permission flag is missing, but if it was already enabled - the command still silently succeeds (which leads to users confusion)

The solution

• Make the enable/disable commands output more specific and user-friendly (suggest a way to enable experimental modules)
• Add warning on trying to enable/disable a module, which is already enabled/disabled

Before

After

📦 Additional module refactoring

• Along the way of fixing the main issue I refactored the structure and naming of modules

---

🏗️ Structural Changes

Before Refactoring

internal/system/cmd/module/
├── applynow/
├── approve/
├── disable/
├── enable/
├── list/
├── module.go
├── operatemodule/        ← "god package" with all logic
├── snapshots/
├── v1alpha1/
└── values/

After Refactoring

internal/system/cmd/module/
├── api/
│   └── v1alpha1/         ← K8s API types (clean rename).    -> looks similar to the main schema naming of deckhouse 
├── cli/                  ← CLI-specific logic (new package)
├── cmd/                  ← All Cobra commands (new nesting) -> some other commands already had this layout 
│   ├── applynow/
│   ├── approve/
│   ├── disable/
│   ├── enable/
│   ├── list/
│   ├── module.go
│   ├── snapshots/
│   └── values/
├── const/                ← Constants (new package).   -> has k8s client timeout constant 
├── deckhouse/            ← Deckhouse API interaction. -> has curl-like query function 
├── moduleconfig/         ← ModuleConfig logic         -> enable/disable module functionality
└── modulereleases/       ← ModuleRelease logic        

---

📁 Moves and Renames

1. API Types

Before	After
v1alpha1/	api/v1alpha1/

Why: Standard Go convention — API types are placed in an api/ directory, and deckhouse also has similar layout.

---

2. CLI Commands → cmd/

Before	After
module.go	cmd/module.go
enable/enable.go	cmd/enable/enable.go
disable/disable.go	cmd/disable/disable.go
approve/approve.go	cmd/approve/approve.go
applynow/applynow.go	cmd/applynow/applynow.go
list/list.go	cmd/list/list.go
values/values.go	cmd/values/values.go
snapshots/snapshots.go	cmd/snapshots/snapshots.go

Why: Isolate Cobra commands from business logic. Clear separation of the presentation layer.

---

3. Decomposition of operatemodule/ (god package)

Before (in operatemodule/)	After	New Package
cli_completion.go	cli/completion.go	cli
cli_messages.go	cli/output.go	cli
optionsmodule.go	deckhouse/api.go	deckhouse
switchmodule.go	moduleconfig/enabled_state.go	moduleconfig
modulerelease.go	modulereleases/module_release.go	modulereleases
release_filter.go	modulereleases/release_filter.go	modulereleases
version.go	modulereleases/version.go	modulereleases

Why: operatemodule was a "god package" — it mixed CLI logic, ModuleConfig operations, and ModuleRelease handling. Now each package is responsible for a single domain.

---

🆕 New Files

File	Purpose
cli/k8s_dynamic_client.go	Creates dynamic K8s client from Cobra flags (less duplication)
const/k8s_operations_timeout.go	Timeout constants

---

✏️ Function Renames

Before	After	Package
OptionsModule()	QueryAPI()	deckhouse
OperateModule()	SetEnabledState()	moduleconfig

Why:

• QueryAPI — more accurate name, the function queries the internal Deckhouse API with curl inside of the pod.
• SetEnabledState — clearly describes what the function does: sets the spec.enabled field in ModuleConfig.

---

✏️ Type and Constant Renames in moduleconfig

Before	After
ModuleState	EnabledState
ModuleEnabled	Enabled
ModuleDisabled	Disabled
OperateResultStatus	ResultStatus
OperateResult	Result
ResultChanged	Changed
ResultAlreadyInState	AlreadyInState

Why: Since the package is already named moduleconfig, prefixes like Module and Operate are redundant. Cleaner API:

// Before
module_config.OperateModule(client, name, module_config.ModuleEnabled)

// After  
moduleconfig.SetEnabledState(client, name, moduleconfig.Enabled)

---

🎯 Summary of Design Principles

1. Separation of Concerns — breaking the monolithic operatemodule into logical units
2. Standard Go Layout — api/, cmd/ structure
3. Single Responsibility — each package owns its domain:
   • cli — user interaction
   • moduleconfig — ModuleConfig logic
   • modulereleases — ModuleRelease logic
   • deckhouse — Deckhouse API
4. Clean Naming — remove redundant prefixes when package name provides context
5. Go Naming Conventions — package names use moduleconfig and modulereleases (no underscores) to follow Go standards