feat(bff): update bff service filtering to match model registry services by component: model-registry label

[ederign]

Description

This PR sits on top of #630 and update bff service filtering to match model registry services by component: model-registry label.

In this specific PR: (commit)

• clients/ui/bff/README.md : add a FAQ section detailing what is setup on env test mock and also how we do model registry service filtering
  On clients/ui/bff/internal/integrations/k8s.go
• Removed some duplicated logic on GetServiceNames()
• On GetServiceDetails, removed component filtering in favor of label filtering (much more efficient)
• I've also make all context with similar values (30seconds)
• clients/ui/bff/internal/mocks/k8s_mock.go: added label for our 3 services and created a new one without the label.

As illustration, I've I remove the label filtering:

curl -i -H "kubeflow-userid: [email protected]" localhost:4000/api/v1/model_registry                                                                         (kind-kubeflow/default)
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
Date: Tue, 10 Dec 2024 15:10:16 GMT
Content-Length: 556

{
	"data": [
		{
			"name": "model-registry-dora",
			"displayName": "Model Registry Dora",
			"description": "Model Registry Dora description"
		},
		{
			"name": "model-registry",
			"displayName": "Model Registry",
			"description": "Model Registry Description"
		},
		{
			"name": "model-registry-bella",
			"displayName": "Model Registry Bella",
			"description": "Model Registry Bella description"
		},
		{
			"name": "non-model-registry", <----- WRONG
			"displayName": "Not a Model Registry",
			"description": "Not a Model Registry Bella description"
		}
	]
}

With filtering:

curl -i -H "kubeflow-userid: [email protected]" localhost:4000/api/v1/model_registry                                                                         (kind-kubeflow/default)
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json
Date: Tue, 10 Dec 2024 15:31:35 GMT
Content-Length: 413

{
	"data": [
		{
			"name": "model-registry-dora",
			"displayName": "Model Registry Dora",
			"description": "Model Registry Dora description"
		},
		{
			"name": "model-registry",
			"displayName": "Model Registry",
			"description": "Model Registry Description"
		},
		{
			"name": "model-registry-bella",
			"displayName": "Model Registry Bella",
			"description": "Model Registry Bella description"
		}
	]
}
```

## How Has This Been Tested? 
Basic sanity check of the app

## Merge criteria:
<!--- This PR will be merged by any repository approver when it meets all the points in the checklist -->
- All the commits have been [_signed-off_](https://github.com/kubeflow/community/tree/master/dco-signoff-hook#signing-off-commits)  (To pass the `DCO` check)

<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
- [X] The commits have meaningful messages; the author will squash them after approval or in case of manual merges will ask to merge with squash.
- [X] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
- [X] The developer has manually tested the changes and verified that the changes work.
- [X] Code changes follow the [kubeflow contribution guidelines](https://www.kubeflow.org/docs/about/contributing/).
 

[ederign]

As soon as you are able to review and (if it's all right) merge #630, I'll rebase this PR

[Griffin-Sullivan]

Testing the mock mode and everything works. Need someone else to do the live cluster testing.

[Griffin-Sullivan]

Is it safe to assume the MR team won't change this port name?

[ederign]

I guess so, otherwise it would need to change the contract of the service.

[Griffin-Sullivan]

I know this is code from before, but is there a case where this would ever happen when deploying MR?

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Griffin-Sullivan

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:

• clients/ui/OWNERS [Griffin-Sullivan]

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

[alexcreasy]

/lgtm