Tailor kube-api-linter configuration for CRD-based APIs #3226

What problem are you trying to solve?

#2618 integrated kube-api-linter (KAL) into CI, but left the linter configuration empty:

settings:
  linters: {}
  lintersConfig: {}

As pointed out by @JoelSpeed in a post-merge review comment (#2618 (comment)), KAL's defaults are a sensible selection for APIs implemented as built-in or aggregated APIs, not for CRDs. Karpenter's APIs (NodePool, NodeClaim, ...) are CRDs, so the current defaults can produce advice that is inappropriate for this repo, for example:

• The conditions linter defaults to useProtobuf: SuggestFix and usePatchStrategy: SuggestFix. The KAL docs state protobuf tags and patch strategy are required for in-tree API types but not for CRDs, and recommend setting these to Ignore or Forbid when linting CRD-based types.
• The nonpointerstructs linter is enabled by default, but its docs say it is not intended for CRD types (optionalfields/requiredfields should be used instead).
• The optionalfields linter defaults to pointers.preference: Always, while CRD-oriented configs (e.g. openshift/api) use WhenRequired.

Proposed solution

Tailor the KAL config for CRDs, using the openshift/api config as a reference, e.g.:

• Set conditions.useProtobuf / conditions.usePatchStrategy to Ignore
• Disable nonpointerstructs
• Evaluate optionalfields pointer/omitempty policies
• Incrementally consider enabling CRD-relevant opt-in linters (nobools, nomaps, maxlength, statussubresource, ...) based on how many new findings they surface against pkg/apis/

Note: KAL upstream is working on an option to automatically apply CRD-appropriate defaults, so this config may be simplified once that lands.

How important is this feature to you?

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• Comments asking for updates generate extra noise for issue followers and do not help maintainers prioritize issues. If you think the issue is higher priority than it is labelled, please instead add your user story.
• If you are interested in working on this issue or have submitted a pull request, please assign yourself

I'm happy to work on this as a follow-up to #2618.

/assign