fix(resources-management): parse fractional CPU and memory quantities

[Suselz]

What is broken

helm_lib_resources_management_cpu_units_to_millicores and
helm_lib_resources_management_memory_units_to_bytes convert a quantity with atoi, which is
strconv.Atoi with the error discarded. It parses integers only, so every fractional quantity
becomes 0 — silently, without an error:

cpu "0.5"   -> 0
cpu "0.5m"  -> 0.5      (not an integer number of millicores)
cpu "500m"  -> 500
cpu "1"     -> 1000
mem "0.5Gi" -> 0

Kubernetes accepts a decimal mantissa, so 0.5 and 500m denote the same amount of CPU, and
0.5Gi is a valid amount of memory.

Why it reaches users

helm_lib_resources_management_original_pod_resources copies requests from the raw value while
computing limits through the conversion, so the two disagree. With vpa.cpu.min set to a
fractional value and a limitRatio:

limits:
  cpu: 0m
  memory: "0"
requests:
  cpu: "0.5"
  memory: 0.5Gi

The API server rejects such a pod: requests must not exceed limits.

The schemas of the consuming modules let these values through. In istio and cni-cilium the
memory pattern is ^[0-9]+(\.[0-9]+)?(E|P|T|G|M|k|Ei|Pi|Ti|Gi|Mi|Ki)?$, which permits a decimal
part outright. The CPU pattern ^[0-9]+m?$ rejects the quoted form "0.5", but the schema also
allows type: number, so an unquoted 0.5 passes validation and then breaks.

The reason this has gone unnoticed is that the affected branch is opt-in: no limits are computed
unless limitRatio is set, and it has no default. Every documented example uses m and Mi
notation.

What this pull request changes

Both helpers now resolve the mantissa and the multiplier first, then convert:

• an integer mantissa keeps exact integer arithmetic, so no value that works today changes its
  result, including the large binary suffixes where float arithmetic would lose precision;
• a fractional mantissa goes through float arithmetic and is rounded up, so a limit is never
  smaller than the value asked for.

The CPU helper also gained the validation that the memory helper already had. An unparsable value
now fails the rendering instead of silently yielding 0.

Please weigh that last point: it is a behaviour change. A value that reaches this branch already
produced limits.cpu: 0m, which the API server rejects, so it cannot be a working configuration
today. Failing loudly seemed better than keeping a silent zero, but say so if you would rather keep
the helpers permissive and fix only the parsing.

Verification

helm unittest ./tests — 411 tests pass, including the existing snapshot. The two helper suites
gained cases for fractional values, a leading-dot value, an unquoted YAML number, and rounding up
of a fractional millicore.

Rendering helm_lib_resources_management_original_pod_resources with the same input as above now
gives a valid object, and the whole-unit case is byte-for-byte unchanged:

unquoted_number_cpu_min:
  limits:
    cpu: 750m
    memory: "402653184"
  requests:
    cpu: "0.5"
    memory: 256Mi
millicores_unchanged:
  limits:
    cpu: 75m
    memory: "402653184"
  requests:
    cpu: 50m
    memory: 256Mi

Release

The chart version is bumped to 1.72.23. The platform picks the fix up through
make update-lib-helm version=1.72.23, which also moves LIB_HELM_VERSION in its Makefile,
currently pinned at 1.72.21.

Context

Found while fixing the same defect in the user-authn module of the platform, where a
DexAuthenticator with cpu: "0.5" rendered an init container with limits.cpu: 0m against
requests.cpu: 10m and stopped the main queue:
deckhouse/deckhouse#23170.

charts/helm_lib/README.md is regenerated by go run tools/build-doc.go.