improve bpfman-operator application conditions so that they follow established conventions

[andreaskaris]

Conditions transitions from:

    conditions:
    - lastTransitionTime: "2025-10-23T12:24:02Z"
      message: Waiting for Bpf Application Object to be reconciled on all nodes
      reason: Pending
      status: "True"
      type: Pending

To:

  status:
    conditions:
    - lastTransitionTime: "2025-10-23T12:24:22Z"
      message: BPF application configuration successfully applied on all nodes
      reason: Success
      status: "True"
      type: Success

The Pending condition is removed. But IMO that's not how it should work in k8s.

https://kubebuilder.io/reference/good-practices#why-you-should-adopt-status-conditions

We recommend you manage your solutions using Status Conditionals following the [K8s Api conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md) because:

    Standardization: Conditions provide a standardized way to represent the state of an Operator’s custom resources, making it easier for users and tools to understand and interpret the resource’s status.
    Readability: Conditions can clearly express complex states by using a combination of multiple conditions, making it easier for users to understand the current state and progress of the resource.
    Extensibility: As new features or states are added to your Operator, conditions can be easily extended to represent these new states without requiring significant changes to the existing API or structure.
    Observability: Status conditions can be monitored and tracked by cluster administrators and external monitoring tools, enabling better visibility into the state of the custom resources managed by the Operator.
    Compatibility: By adopting the common pattern of using conditions in Kubernetes APIs, Operator authors ensure their custom resources align with the broader ecosystem, which helps users to have a consistent experience when interacting with multiple Operators and resources in their clusters.

The conditions should IMO not be removed after they are no longer true, so Pending should remain as a condition forever. I'm not sure if it should transition from Unknown to True to False, or if it should stay True forever (in deployments, Progressing definitely stays True forever, but Available then switches to True and that's how one knows that the deployment is done via conditions.

However, https://superorbital.io/blog/status-and-conditions/ makes a good point:

When a Condition’s "True" status represents normal operations, it is referred to as a “positive-polarity” condition, whereas Conditions where "False" represents this state are “negative-polarity”. Standardize all your Conditions to use the same polarity to represent normal operations. This will help avoid confusion when scanning the conditions list and seeing a mix of "True" and "False" status values during normal conditions.

So I'd advocate for having Pending: True coexist with Success: True

See https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md
and https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties

Although they are not a consistent standard, the Ready and Succeeded condition types may be used by API designers for long-running and bounded-execution objects, respectively.

IMO, there should be a condition: Pending which transitions from False to True and the Reason should be more explicit, such as WaitingForReconcile. There should be another condition, Succeeded or Ready and the reason should be

By the way, note that conditions in the STATUS field can and should be tracked with something like:
// +kubebuilder:printcolumn:name="Available",type="string",JSONPath=".status.conditions[?(@.type=='Available')].status"

And not via the index [0] as we're currently doing

[andreaskaris]

/assign