feat: serve workspacekind assets (logos + icons)

[andyatmiami]

closes: #692

This commit implements serving of workspacekind assets (logos and icons) from ConfigMaps through the backend API, with SHA256 hash support for cache-busting.

Key changes:

• Add endpoint to serve workspacekind assets from ConfigMaps at /api/v1/workspacekinds/{name}/assets/{icon|logo}.svg
• Compute and include SHA256 hashes for ConfigMap-based assets as query parameters for cache-busting
• Add ConfigMap client support to repositories for accessing asset content
  • partial cache for performance/efficiency that keys off label:
    • notebooks.kubeflow.org/image-source: true
• Add GetConfigMapContent method to WorkspaceKindRepository and WorkspaceRepository for retrieving asset content from ConfigMaps
• Update model functions to support SHA256 hashes in asset URLs:
  • NewWorkspaceKindModelFromWorkspaceKindWithAssetHashes
  • NewWorkspaceModelFromWorkspaceWithAssetHashes
• Added workspacekind_imagesource_configmap.yaml for reference example
• Refactored backend mgr setup in main.go to leverage helper/k8s.go
  • easier to keep logic in sync in e2e tests - particularly with new partial cache

Remote URL specification of assets is still supported - but the browser queries
the source URL directly for content.

SCREENSHOTS

[google-oss-prow]

[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 ask for approval from andyatmiami. For more information see the Kubernetes Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• workspaces/backend/OWNERS
• workspaces/controller/OWNERS

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

[andyatmiami]

/ok-to-test

[thaorell]

While reviewing the implementation for /api/v1/workspacekinds/{name}/assets/{logo|icon|.svg, I did a quick scan of the existing data flow.
It looks like the frontend/client already receives the full source URL for these icons and logos from ImageRef as part of the parent WorkspaceKind object or a payload from WorkspaceKindInfo in loading workspace(s).

If that's the case, could we simply have the browser render those URLs directly? That would allow us to avoid maintaining a dedicated proxy endpoint and increase maintainability.

Let me know if I’m missing a specific use case where this proxy is required