feat(tenant): add per-class GPU budgets and the vGPU entitlement - #5008

A hoster publishes each GPU offer as a cluster-scoped GPUClass: one
resource name per offer, the tolerations its VMs need on the class's
nodes, and for vGPU classes the license Secret and FeatureType the
guests get. VMs and worker pools name a class instead of a raw
device-plugin name, so the offer can be budgeted per tenant and shown
in a catalog with its free units.

The kind joins cozystack.io instead of a group of its own: a CRD
cannot move between groups in place, and nothing in the design needs
separate versioning or serving. The class name becomes part of the
budget key <class>.gpuclass.cozystack.io/devices, so it is a DNS
label, and a resource name in that domain is refused.

Vendor, model, mode, profile, memory and the source kind never
change, so a class name stands for one offer for its whole life and
billing records keyed by it stay meaningful. A class carries no node
selector: its nodes are the nodes that advertise its resource name.

The CEL tests run the shipped CRD through the apiserver's own prune,
default, schema and CEL steps, so a marker that failed to generate
fails a test instead of admitting a bad class.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

A vGPU class may be used only by an entitled tenant, and no tenant may
grant itself the entitlement. The Tenant field gpu.vgpu is set by the
parent's administrator, so the effective value is the field and the
parent's value together, and it reaches the namespace as the
namespace.cozystack.io/vgpu label. The label is always written, so
only "true" entitles and a missing label cannot be read as consent.
_namespace.vgpu is written only when entitled, since every app in the
tenant reads that Secret and an always-present key would upgrade them
all.

GPU budget keys in the gpuclass.cozystack.io domain are checked when
a VM or a worker pool is written, not against pods, so they are
dropped before the ResourceQuota render, and a tenant with only GPU
budgets gets no ResourceQuota or LimitRange. The domain test matches
the one the API server uses, so a malformed budget key never becomes
a pod quota either.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

The tenant chart renders its ResourceQuota and the default LimitRange
only for keys other than the gpuclass.cozystack.io GPU budgets, so a
tenant with only GPU budgets has no LimitRange. The comments and the
system memory limits page that explain sidecar sizing and system
defaults by that LimitRange said any declared resourceQuotas brings
it.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>

GPU budgets are not pod resources, so ResourceQuota cannot enforce them.
Until the pool-wide admission gate is available, the API server needs
to check declared class reservations to avoid accepting applications
that exceed a tenant's budget. Reusing its inputs and pool arithmetic
keeps the eventual switch from changing admission decisions.

Tenant quota allocation must account for those reservations because
ResourceQuota usage cannot report them. Ordinary-resource accounting
must retain GPU-only descendants in the parent's pool, matching the
tenant chart and runtime controller. Unsupported keys in the GPU budget
domain must not create an unenforced promise when the chart omits them.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <[email protected]>