Teleterm: add support for access requesting kube namespaces

[kimlisa]

part of #46742

requires:

• Add a new role.options field called request_mode.kubernetes_resources #47173
• Web: implement requesting for kube namespace selector #47345
• Teleterm: Add listing kube resources endpoint #46753

if you want to test connect, i have a staging cluster that i can invite to then:

1. OS: check out branch lisa/connect-team (it has all the necessary PRs stiched)
2. build tsh, and then pnpm start-term and login to my cluster

when request mode requires you to request for namespace

  ... rest of role
  options:
    request_mode:
      kubernetes_resources:
      - kind: namespace   # wildcard '*' enforces the same namespace requirement on the UI (since UI only supports namespace selection)

when request mode is a kind that UI doesn't support, it disables the checkout regardless of other resources (it is enabled once user removes the kubernetes):

  ... rest of role
  options:
    request_mode:
      kubernetes_resources:
      - kind: pod   # only namespace is supported on the web UI, tsh supports all

demo (when no request mode is specified, allows requesting for a kube_cluster or a kube_clusters namespace):

  ... rest of role
  options:
    # no request mode defined

Screen.Recording.2024-10-08.at.11.58.11.PM.mov

changelog: Add Connect support for selecting Kubernetes namespaces during access requests

[github-actions]

The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with changelog: followed by the changelog entries for the PR.

[github-actions]

The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with changelog: followed by the changelog entries for the PR.

[gzdunek]

I don't think we the need optional chaining here.

[gzdunek]

And here.

[gzdunek]

This is unused, no?

But I wonder if it wouldn't be more convenient to keep the selected namespaces here, instead of having them as a separate resource (line 313).
Pros:

1. We wouldn't need to remember about removing kube_cluster resources (from UI/API requests) when there are namespaces selected.
2. We wouldn't have to remove namespaces manually when a "parent" kube_cluster is removed from the access request.

Cons:

1. This would differ from shared types where the namespace is a regular requestable resource. OTOH I feel that the proposed data model is more correct.

I can imagine having a function like this one in AccessRequestsService:

  async addOrRemoveKubeNamespace(resourceUri: KubeResourceNamespaceUri) {
    this.setState(draftState => {
      if (draftState.pending.kind !== 'resource') {
        throw new Error('Cannot add a kube namespace to a role access request');
      }

      const { resources } = draftState.pending;

      const requestedResource = resources.get(
        routing.getKubeUri(
          routing.parseKubeResourceNamespaceUri(resourceUri).params
        )
      );
      if (!requestedResource || requestedResource.kind !== 'kube') {
        throw new Error('Cannot add a kube namespace to a non-kube resource');
      }
      const kubeResource = requestedResource.resource;
      if (!kubeResource.namespaces) {
        kubeResource.namespaces = new Set();
      }
      if (kubeResource.namespaces.has(resourceUri)) {
        kubeResource.namespaces.delete(resourceUri);
      } else {
        kubeResource.namespaces.add(resourceUri);
      }
    });
  }

Please let me know what do you think about it :)

[gzdunek]

What do you think of returning Promise<string> here?
We could do the mapping to Option in KubeNamespaceSelector.