[Service Mesh]: handle istio proxy events

[cam-garrison]

Closes: #1935

Description

This PR adds displaying the various event states when pulling the istio-proxy container. Before this PR, the percentage is not updated for the different stages of pulling the istio-proxy container as it was for the oauth-proxy container.

This is implemented by adding a function wrapping around the switch statement previously used for oauth-proxy, and now can be used for either oauth or istio proxy depending on which is being pulled/started. The helper function capitalizeFirstLetter is used to maintain the same messages as before (in terms of capitalizing Oauth vs oauth).

Note: the 'pulling istio proxy' message should not appear - this proxy sidecar will be pulled for the dashboard's sidecars as well so.

How Has This Been Tested?

Tested by installing operator v2 with service mesh: see opendatahub-io/opendatahub-operator#605. Then, tested creating notebooks from the jupyter tile and from a data science project to ensure that the "Istio proxy container started" message is shown last. Also, tested with ODHDashboardConfig.disableServiceMesh=true in both cases to see that Oauth related event messages are still shown.

Test Impact

I am not sure where to add tests for this kind of a change - please point me in the right direction if testing would be needed for this PR!

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

[cam-garrison]

@andrewballantyne could you take a look at this when you have some bandwidth?

[andrewballantyne]

If this feature has a path to RHOAI, I need you to clean up some of this (which I can give you direction on). Waiting for your response on slack or here.

/hold

For now let's just hold up this change.

[andrewballantyne]

Dang -- these kind of PRs remind me all the tech debt we need to do to get away from the Jupyter Tile 😞 -- not your problem though. Can you just update the code to be less open-ended and then we can go ahead with this (do it in both files please).

/approve

Just made the code changes and we can lgtm this.

[andrewballantyne]

/unhold

It's not awesome, but there is little to do here other than get started on that refactor to get rid of the custom Jupyter tile logic (which is really in most cases duplicate of our Projects view)

[andrewballantyne]

Please do to both areas @cam-garrison & squash commits into a single commit always. Rebase your PR if you need to, never merge to save you the headache when squashing.

Let me know if you have any questions about this.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andrewballantyne

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 [andrewballantyne]

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