Fleet Epic: Statuses refactoring

[torchiaf]

Is your feature request related to a problem? Please describe.

We want to revisit the status of each Fleet resource in order to be consistent with the actual resource statuses.

Related issues:

• Fleet clusters not reflecting disconnection under Continuous delivery rancher#47514
• If any clusters are offline, bundle status can get stuck fleet#594

Describe the solution you'd like

• We should consider to better calculate statuses backend side so that the UI could reduce the effort to normalize data and calculate new statuses
• UI should calculate statuses considering that we want to implement pagination for some Fleet tables (Dashboard/GitRepo list).

Describe alternatives you've considered

Additional context

[richard-cox]

Vai-cache on will impact this in some way

• when fleet updates to use the new cache (there will be new guidance and docs for this)
  • update lists to use the new paginated table resources with high counts
  • update drop downs that are powered by resources with high counts
  • remove usages of findAll for resource types that have high resource counts
• this means
  • any new lists that are implemented should only filter/sort on fields that exist in the primary resource (because it will be powered by API request to a single resource type)
  • any new pages / components that are created should avoid using findAll when fetching resources

Some of this might not be possible given the replacement to findAll isn't yet available, but we should plan around it

[richard-cox]

The state in the ui comes from the resource's metadata.state.name|message. Those are constructed by steve very roughly by kstatus from the resource's conditions (see confluence page Dynamic Resource Properties)