[deckhouse-cli] Fix RPP access docs and the TLS flag that could not help

[Glitchy-Sheep]

Summary

Two things blocked downloads through registry-packages-proxy: the docs named a ClusterRole that grants nothing, and the only TLS escape hatch covered the wrong connection. Both are fixed, and every claim is checked against the code.

Problem

The docs sent admins to the wrong role:

• plugins.md said plugins need d8:registry-packages-proxy:packages-download, and that it differs from self-update's cli-download. Both wrong.
• Plugins live under deckhouse-cli/plugins/<name> and travel the same /v1/images/ route, guarded by the cli-binary subresource. cli-download covers them.
• An admin following these docs bound a role that grants nothing, and downloads kept returning 403.
• Both pages said authorization is cached for about 5 minutes and told the user to fetch a fresh token. A denial clears in 30 seconds; a new token changes nothing.
• Neither page mentioned that endpoint discovery reads the registry-packages-proxy Ingress. Without that permission the command dies before it reaches the proxy.
• internal/selfupdate/README.md listed the download route as /v1/images/deckhouse-cli/tags/<tag>, which the proxy does not serve.

The insecure flag covered the wrong connection:

• d8 cli and d8 plugins open two TLS connections: one to the Kubernetes API server for endpoint discovery, one to the proxy for downloads.
• --rpp-insecure-skip-tls-verify relaxed only the second one.
• So an API server certificate the client cannot verify killed every command, with no flag to get past it. The only way out was editing the kubeconfig by hand.
• Hit on a dev cluster: the API server ingress lost its TLS secret and served the ingress-nginx fallback certificate. Every command died on x509: certificate is valid for ingress.local, and the old flag changed nothing.

Fix

Docs:

• One role for everything: cli-download covers d8 cli and d8 plugins.
• Real cache numbers, with the practical advice ("retry in half a minute").
• Both pages name the Ingress read permission.
• The download route is /v1/images/deckhouse-cli/images/<version>?platform=<os>-<arch>.
• Both pages link to the module docs for the grant commands, so the recipe lives in one place.

Flag:

• --insecure-skip-tls-verify relaxes both connections.
• It works through a clientcmd override, the same way kubectl does it, so the kubeconfig CA is dropped instead of colliding with the insecure setting.
• The kubeconfig identity (token, client certificate, exec plugin) is untouched. Only server trust changes.
• --rpp-insecure-skip-tls-verify is removed. It could not solve the failure people actually hit, and two flags for one idea invited picking the wrong one.
• Endpoint-discovery diagnostics name the flag, so the error itself points at the fix.

Tests

New unit tests in internal/utilk8s/clientset_test.go:

• TestSetupK8sClientSetVerifiesByDefault - a kubeconfig with a CA still verifies.
• TestSetupK8sClientSetInsecureDropsCA - the option turns verification off, clears the CA, keeps the bearer token.
• TestSetupK8sClientSetInsecureFalseKeepsCA - passing false changes nothing.

Run against a dev cluster whose API server ingress served the fallback certificate:

Run	Result
no flags	x509: certificate is valid for ingress.local
--rpp-insecure-skip-tls-verify (old flag)	same failure
--insecure-skip-tls-verify	A newer deckhouse-cli is available
d8 plugins versions <name> --insecure-skip-tls-verify	version list returned
kubeconfig with a valid CA, no flag	reaches the proxy, 401 as expected - verification not weakened