Handle Removed but not Disabled DS Pipelines

[andrewballantyne]

Closes: #1870

Description

When DSP is disabled in v2 Operator, the context fails and blocks the rendering of DS Projects details view.

Screenshots / Flow

Two users:

1. Cluster Admin - The cluster admin can read 404 normally when an API is not available (404 error)
2. Regular user (eg. admin with no special permissions) - The regular user cannot read API from one that does not exist (403 error)
   • This will be done through impersonate, same difference on cluster (the screenshot has a white button in the header)

Note: There are a lot of screenshots to show each state, so I added collapsible sections. Expand each one to see the screenshots. Two sets will be provided in each section. One for the cluster-admin and one for the "regular user".

DS Projects - No Operator installed & No DS Pipelines Component

Screenshots

---

DS Projects - Operator installed & No DS Pipelines Component

Screenshots

Global Screens (Pipeline & Run) - Operator installed & No DS Pipelines Component

Screenshots

---

DS Projects - Everything installed

Screenshots

Global Screens (Pipeline & Run) - Everything installed

Screenshots

How Has This Been Tested?

Three layers of testing here

• First layer is nothing installed, no operator & no component << Was the bug, installing the operator got a different error
• Second layer is just operator, no component << Once the first layer is removed, the error changes
• Third layer is both operator & component << Once the second layer is removed, we successfully render

Normal flows continue after this.

Test Impact

Deferring tests to #2010. This is a temporary fix to still show errors in the UI -- but nicer. To properly support components against our feature flags we need 2010, where tests should be included.

Request review criteria:

Self checklist (all need to be checked):

• The developer has manually tested the changes and verified that the changes work
• Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

• Included any necessary screenshots or gifs if it was a UI change.
• Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

• The developer has tested their solution on a cluster by using the image produced by the PR to main

[christianvogt]

scenarios work as described
/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: christianvogt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [christianvogt]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[manosnoam]

Verified on RHOAI 2.5