Add --namespace-list flag to accept a slice of namespaces

[GuessWhoSamFoo]

What this PR does / why we need it:
Adds a --namespace-list flag which accepts a slice of namespaces in the form of x,y,z and validates each via Get rather than List for users who have restricted clusters.

Which issue(s) this PR fixes

• Fixes Static namespace list #911

[wwitzel3]

I can't decide if we should just extend the --namespace flag to support invoking with a single value or a list or if we should add a new flag. I envisioned this extending --namespace

[GuessWhoSamFoo]

The only benefit to setting this up as a separate flag is if a user wants to provide namespaces but not necessarily start octant on any of them. I don't think that merits a different flag - going to change this

[wwitzel3]

Make sure we document that the first namespace becomes the initial/default namespace when Octant loads.

[wwitzel3]

Ok, sorry @GuessWhoSamFoo but now I'm leaning back towards a separate flag. When I start to think about how to document this flag, there ends up being too many AND/ORs in it and it gets a little muddy. I think you had it right the first time, but maybe we call it --namespace-list ? To help disambiguate it from --namespace.

--namespace - sets the startup namespaces.
--namespace-list - explicitly sets the namespaces Octant will provide in the namespace selector.

[GuessWhoSamFoo]

Rebased on master and changed flag name

[wwitzel3]

Let's get this better documented, something like.

a list of namespaces to make available, if not set, Octant will attempt to list namespaces from the cluster

[merlindorin]

Top! thx

[tonyfalabella]

Can --namespace-list use wildcards? If not is it something you can add? Our company has many namespaces but for a given team all namespaces have a certain pattern.

I'd like to be able to use like this:
octant --namespace-list foo*,bar*,xyz

[GuessWhoSamFoo]

That sounds like a reasonable request. Opened an issue for tracking

[merlindorin]

@GuessWhoSamFoo I'm not sure if it's a good idea.

Under the hood, --namespace-list provide a static namespace list (no rights on kubeAPI namespace list). With a feature like a wildcard... we will have to list all namespaces available (needs kubeAPI namespace list rights) and then we will apply a filter.

It will be hard for a user with no rights on kubeAPI namespace list to understand why --namespace-list foo-bar works and why --namespace-list foo-* does not.

Maybe it can be something like --namespace-filter ?