Add displayName and description to GetServiceDetails

[Griffin-Sullivan]

Description

Add displayName and description when we get service details from the cluster. This is based off of the fact that we expect MR or the user deploying the MR service to add the displayName and description to annotations on the service.

How Has This Been Tested?

1. To reproduce deploy a kind cluster locally following the guide
2. Run BFF in live mode like make run PORT=4000 MOCK_K8S_CLIENT=false MOCK_MR_CLIENT=false
3. Get model registries with curl http://localhost:4000/api/v1/model_registry. You should see the BFF log a couple errors because you will be missing a displayName and description

{
	"data": [
		{
			"name": "model-registry-service",
			"displayName": "",
			"description": ""
		}
	]
}

4. Now stop the BFF and add the displayName and description to the service annotations by running:

kubectl edit svc model-registry-service -n kubeflow

apiVersion: v1
kind: Service
metadata:
  annotations:
    description: a very nice model registry
    displayName: default model registry
...

5. Run the BFF again and curl for the model registries to see our displayName and description

{
	"data": [
		{
			"name": "model-registry-service",
			"displayName": "default model registry",
			"description": "a very nice model registry"
		}
	]
}

6. Also verify that the UI handles this change properly (I added another empty annotation service to compare side by side):
   

Merge criteria:

• All the commits have been signed-off (To pass the DCO check)

• The commits have meaningful messages; the author will squash them after approval or in case of manual merges will ask to merge with squash.
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has manually tested the changes and verified that the changes work.
• Code changes follow the kubeflow contribution guidelines.

If you have UI changes

• The developer has added tests or explained why testing cannot be added.
• Included any necessary screenshots or gifs if it was a UI change.
• Verify that UI/UX changes conform the UX guidelines for Kubeflow.

[ederign]

Thank you Griffin! We are still lacking test coverage on this, but I'll send this together with the PR on the envtest!

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ederign

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

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

[ederign]

/lgtm