feat(k8s): Support for Kubernetes envvar_only lookups

[saamalik]

Description

Add support for module activation to only look at $KUBECONFIG envvar instead of also the default ~/.kube/config.

Motivation and Context

A common K8s workflow is to have your ~/.kube/config pointing to your default K8s cluster, but then override individual terminals/panes to another cluster (using a dedicated $KUBECONFIG). This minor feature enhancement adds support for Starship to highlight only overriden panes/terminals. See screenshots below.

Also see article for more info: https://www.spectrocloud.com/blog/how-to-quickly-switch-between-kubernetes-clusters/.

Screenshots (if appropriate):

Top pane (and all other terminals) don't need to keep showing my default cluster (e.g: picard), whereas any pane/terminal explicitly overriding $KUBECONFIG shows the cluster name.

How Has This Been Tested?

• Added Unit tests
• [X] I have tested using MacOS
• [X] I have tested using Linux
• [x] I have tested using Windows

Checklist:

• [X] I have updated the documentation accordingly.
• [X] I have updated the tests accordingly.
• [ ] TODO: need help with creating a test that configures the ~/.kube/config in a sandbox (or we can drop this test, since we're currently don't have any tests for ~/.kube/config?)

[andytom]

I like this idea but I would prefer it to implement this in a more general way. I think if we could do this similar to the detect_* settings we use for files and directories. Something like detect_envvars and the logic inside the module would be if the list is empty the module is activated, if the list is non empty and one or more of the env vars in the list are set the module is active and if the list is non empty and all the env vars in the list are not set then the module is not active.

This approach should be more flexible if, for example, there is another work flow that uses new/different env vars and something we could implement in other modules and keep a consistent configuration pattern across all modules.

[saamalik]

@andytom - sounds good. I'll take a stab over the weekend.

[jankatins]

This could also be accomplished in a more general way by the ignore feature in https://github.com/starship/starship/pull/4505/files

[Hustenbonbon]

I like this idea but I would prefer it to implement this in a more general way. I think if we could do this similar to the detect_* settings we use for files and directories. Something like detect_envvars and the logic inside the module would be if the list is empty the module is activated, if the list is non empty and one or more of the env vars in the list are set the module is active and if the list is non empty and all the env vars in the list are not set then the module is not active.

This approach should be more flexible if, for example, there is another work flow that uses new/different env vars and something we could implement in other modules and keep a consistent configuration pattern across all modules.

I think I understand the intention, but formulating my own needs before I looked if there are open PRs, just looking for $KUBECONFIG is what I believe >95% of people using this module would want. I would be happy to see either this PR (my preference) or the more generelized version merged.