Follow-up to PR #485: Use non-pointer type for status Priority field

[frobware]

Summary

This is follow-on work from PR #485 which addressed issue #484 (allowing priority: 0 for BPF programs). PR #485 correctly changed the spec Priority field from int32 to *int32, but also changed the status field to a pointer type. This PR explores and implements using a non-pointer type for the status field instead.

Problem with pointer type in status

The status Priority field was annotated +required but declared as *int32 with json:"priority,omitempty" - these are contradictory: a required field should not be a pointer with omitempty, as that allows it to be absent from the serialised output.

Since the controller always resolves a concrete priority value (either the user's explicit value or the default 1000), the status field should be int32. The status represents what was actually applied to the system, and that is never "unset".

Changes

1. Revert status types to int32: Change AttachInfoState Priority fields back to int32 for all program types (XDP, TC, TCX and their cluster variants)
2. Update reconcilers: Use GetPriority() only for spec fields, use direct int32 values for status
3. Remove unused helper: Remove GetPriorityPointer() which is no longer needed
4. Update tests: Fix unit and integration tests for the new status type
5. Define public constant: Add DefaultAttachPriority as a public API constant for the default value (1000)

Design

Field Location	Type	Behaviour
Spec (AttachInfo)	*int32	Optional - nil means "use default", 0 means "explicit zero"
Status (AttachInfoState)	int32	Required - always set by controller to actual applied value

Cluster Testing

Test 1: Explicit priority: 0

Created a ClusterBpfApplication with priority: 0:

apiVersion: bpfman.io/v1alpha1
kind: ClusterBpfApplication
metadata:
  name: priority-zero-test
spec:
  nodeSelector: {}
  byteCode:
    image:
      url: quay.io/bpfman-bytecode/go-xdp-counter:latest
  programs:
    - name: xdp_stats
      type: XDP
      xdp:
        links:
          - interfaceSelector:
              primaryNodeInterface: true
            priority: 0

Result - Spec preserved priority: 0:

spec:
  programs:
  - xdp:
      links:
      - priority: 0

Result - Status shows priority: 0:

status:
  programs:
  - xdp:
      links:
      - priority: 0
        linkStatus: Attached

Result - bpfman confirms Priority: 0:

 BPF Function:       xdp_stats
 Priority:           0
 Position:           0

Test 2: Default priority (not specified)

Created a ClusterBpfApplication without specifying priority:

apiVersion: bpfman.io/v1alpha1
kind: ClusterBpfApplication
metadata:
  name: priority-default-test
spec:
  programs:
    - name: xdp_stats
      type: XDP
      xdp:
        links:
          - interfaceSelector:
              interfaces:
                - eth1

Result - Status shows priority: 1000 (default applied by controller):

status:
  programs:
  - xdp:
      links:
      - priority: 1000

Schema verification

$ kubectl explain clusterbpfapplicationstate.status.programs --recursive | grep priority
      priority	<integer> -required-

The status field is now correctly marked as required.

[mergify]

@frobware, this pull request is now in conflict and requires a rebase.

[frobware]

/hold