What type of PR is this?

/kind bug

What this PR does / why we need it:

This updates the way that the maximum size of an IntOrString is calculated in the CEL cost estimator to take into account an openapi maxlength constraint.

I was working with someone on a field like:

// request is the minimum amount of the resource required (e.g. "2Mi", "1Gi").
	// This field is optional.
	// When limit is specified, request cannot be greater than limit.
	// +optional
	Request resource.Quantity `json:"request,omitempty"`

We then started adding some CEL rules, for example,

	// +kubebuilder:validation:XValidation:rule="isQuantity(self) && quantity(self).isGreaterThan(quantity('0'))",message="request must be a positive, non-zero quantity"

The API server started to complain of high validation costs. Typically this is because the unbounded string length results in a high MaxElements in the cost estimates.

The usual fix would be to add a maximum length, for example:

	// +kubebuilder:validation:MaxLength=20

But this doesn't work initially because of the way controller-gen is applying different parts of the schema, adding

	// +kubebuilder:validation:XIntOrString

Allows it to produce the following schema:

request:
  anyOf:
  - type: integer
  - type: string
  description: |-
    request is the minimum amount of the resource required (e.g. "2Mi", "1Gi").
    This field is optional.
    When limit is specified, request cannot be greater than limit.
  maxLength: 20 // This is the only part we've added on top of the default schema that controller tools produced
  pattern: ^(\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))(([KMGTPE]i)|[numkMGTPE]|([eE](\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))))?$
  x-kubernetes-int-or-string: true
  x-kubernetes-validations:
  - message: request must be a non-negative quantity
    rule: isQuantity(self) && quantity(self).isGreaterThan(quantity('0'))

We then noticed that the cost estimates were still particularly high. It turns out, that the logic handling any XIntOrString field isn't correctly observing the MaxLength.

As far as I can tell, the above is a valid schema and the API server appears to accept this schema, and enforce the maximum string length (note int64 has a maximum length of 19 so the integer max length should be covered by this case too, though CELs cost estimates for integers doesn't set a max elements AFAICT)

This PR updates the logic to take into account the max length and resolves our issue.

Which issue(s) this PR is related to:

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Fix runtime cost estimation for x-int-or-string custom resource schemas with maximum lengths

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: