OSSM: Add service mesh manifests overlay

[cam-garrison]

Description

This PR adds the service mesh overlay to the manifests directory which make changes to odh-dashboard resources enabling service-mesh, as well as a minimal overlay that can be useful when developing/testing on a cluster with low resource limits (ie: CRC).

This is needed for using the new version of the operator, as the v2 operator pulls manifests from the main branch of odh-dashboard rather than from the odh-manifests repo as before.

Unfortunately, due to restrictions with kustomize and patching, two patches have to be added to the base directory - please see comments in said files and overlays/service-mesh/kustomization.yaml for reasoning on this. Patches that are not immediately obvious are commented with reasoning.

These changes should be completely unobtrusive to users not using service-mesh, as the overlays are only enabled when specified - or in our case, when service-mesh is enabled in the v2 operator, the overlay is applied by operator.

How Has This Been Tested?

This has been tested in several ways:

• manually running kustomize build manifests/overlays/service-mesh to ensure that the manifests build correctly using this overlay.
• Using a modified v2 operator (just merged here) to pull in the changes and ensured that the overlays are applied correctly.
• to test above, try adding these args when building v2 operator --build-arg OVERWRITE_MANIFESTS='--odh-dashboard="maistra:odh-dashboard:add-sm-overlay:manifests:odh-dashboard"'"
• In addition, these same overlays have been used in testing for months in the odh-manifests/service-mesh-integration branch.

Test Impact

I do not believe that tests can be created to ensure this overlay - please let me know if there is some way to add tests for this.

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

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign alexcreasy for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[cam-garrison]

closing as this will be part of #1088