[deckhouse-cli] Plugins / d8 self-update with requirements check

[Glitchy-Sheep]

Summary

Adds two ways to keep d8 up to date:

• d8 cli command tree that updates the d8 binary itself
• reworked d8 plugins that installs, updates, and runs plugins.

Both reach the cluster's registry through the in-cluster registry-packages-proxy, authenticated by the user's kubeconfig identity - no registry credentials are handed out.

Plugin operations validate the plugin's declared requirements before anything is downloaded or switched.

New commands

d8 cli - update the d8 binary:

• check - report whether a newer version than the current one is published.
• versions (alias list) - list published versions newest-first; the current one is starred, locally installed ones are marked.
• update [--version X] - install a version into the store and point the binary at it.
• use <version> - switch to a version: an installed one is an instant offline symlink repoint, a missing one is downloaded first.

d8 plugins - manage plugins (standalone binaries that run as native-looking subcommands):

• install <name> [--version X] [--use-major N] [--force] - install or switch a plugin version.
• update <name> / update all - move to the newest cluster-compatible version within the installed major.
• versions <name> - list a plugin's published versions.
• list [--installed|--available] - list plugins.
• contract <name> - show a plugin's contract.
• remove <name> - remove an installed plugin.
• d8 <plugin> ... (wrapper, with DECKHOUSE_PLUGINS_ENABLED=true) - run an installed plugin, auto-installing it on first use.

Requirements validation

A plugin declares its requirements in a contract, and d8 enforces them:

• Cluster-side - Kubernetes, Deckhouse, and module versions (mandatory / conditional / anyOf) are checked against a one-shot cluster snapshot. The cluster is only queried when the plugin actually declares such a requirement.
• Plugin-to-plugin - conflicts with already installed plugins; --resolve-plugins-conflicts tries to pull in missing dependencies.
• When - validated before any download or symlink switch (install, update, and the fast path that only repoints to an already installed version), and again before every plugin run (in case of k8s/module changed).
• Escape hatch - --skip-cluster-checks / D8_PLUGINS_SKIP_CLUSTER_CHECKS=1 for testing purposes

Version selection picks the newest stable version whose cluster-side requirements are satisfied, stays within the installed major unless --use-major is given, and never downgrades implicitly.

How updates are applied

Both d8 cli and d8 plugins share the same atomic scheme:

1. download into a staged file while the live binary keeps working.
2. smoke-test it (a corrupt or wrong-platform artifact is rejected before it replaces anything)
3. back up the previous binary, then atomically swap and repoint a current symlink.
4. A failure at any step leaves the previous version in place.

Example usage

Self-update (d8 cli):

# What is published, and what am I on?
$ d8 cli versions
  v1.60.0  newer
* v1.59.0  current
  v1.58.2

# Is there anything newer?
$ d8 cli check
A newer deckhouse-cli is available: v1.60.0 (current: v1.59.0). Run 'd8 cli update' to upgrade.

# Update to the latest stable
$ d8 cli update
Updating deckhouse-cli to v1.60.0...
deckhouse-cli updated to v1.60.0.
The d8 binary in PATH is now a symlink into the version store; the previous binary is kept with a ".old" suffix.

# Roll back instantly and offline - the previous version is still in the store
$ d8 cli use v1.59.0
Switched deckhouse-cli to v1.59.0 (installed locally).
Previous version v1.60.0 remains installed - switch back with 'd8 cli use v1.60.0'.

Plugins (d8 plugins):

# Inspect before installing
$ d8 plugins versions stronghold
  v1.4.0  newer
  v1.3.0

$ d8 plugins contract stronghold
name: stronghold
version: v1.4.0
description: Vault-fork integration for DKP
requirements:
  kubernetes:
    constraint: '>=1.27'

# Install - the cluster requirements are checked first, then the binary is pulled
$ d8 plugins install stronghold
Installing plugin: stronghold
Tag: v1.4.0
Downloading and extracting plugin...
✓ Plugin 'stronghold' successfully installed!

# Run it as if it were a native subcommand (DECKHOUSE_PLUGINS_ENABLED=true)
$ d8 stronghold status
...plugin output...

# Already current - update is a no-op
$ d8 plugins update stronghold
Updating plugin: stronghold
Plugin 'stronghold' is already at v1.4.0, nothing to do (use --force to reinstall).

$ d8 plugins remove stronghold
✓ Plugin 'stronghold' successfully removed!

A plugin whose requirements the cluster does not meet is rejected before anything is downloaded or switched:

$ d8 plugins install stronghold
Installing plugin: stronghold
Error executing command: failed to validate requirements: kubernetes requirement: \
  plugin stronghold requires Kubernetes >=1.27, but the cluster runs v1.24.3
# exit code 1, nothing installed, current symlink untouched

Refactor

• Dropped the direct-registry plugin service (pkg/registry/service/plugin_service.go and its test, ~1280 lines) so the registry proxy is the single plugin source. The contract decoder it carried is kept as pkg/registry/service/contract.go for reuse.

New packages

• internal/rpp - HTTP client for the registry proxy: kubeconfig-bearer transport (no redirects, so the token never leaves the proxy host), endpoint discovery (public Ingress, with pod-IP fallback), and tar.gz extraction.
• internal/lockfile - an exclusive file lock shared by plugin installs and self-update so two switches cannot run at once.
• internal/selfupdate - the self-update machinery and the per-user version store with its current symlink.
• internal/plugins/requirements - the one-shot cluster snapshot (k8s / Deckhouse / modules) and the named checks run against it.

Tests

• internal/rpp - transport, endpoint discovery, image pull, and tar.gz extraction (transport_test.go, endpoint_test.go, image_test.go, extract_test.go).
• internal/selfupdate - version store and symlink switching, the updater, the RPP source, and an end-to-end update against a fake proxy (store_test.go, update_test.go, switch_test.go, integration_test.go).
• internal/plugins - install pipeline, version selection, requirement checks and cluster snapshot, the run wrapper, and an RPP end-to-end path (install_test.go, select_test.go, requirements/checks_test.go, requirements/clusterstate_test.go, run_test.go, rpp_e2e_test.go).
• internal/lockfile - exclusive locking and stale-lock reclaim (lockfile_test.go).