Add additional env vars to login about ocm-container HOT 2 OPEN

+1 to the overall goal here. Extra ENVs are totally useful, and welcome.

This is tricky. I feel very strongly that ocm-container should be usable without installing any other tools on the host, so we'll either need to code up ocm lookups via token into the golang stuff (which I'm not opposed to - some of that exists here, but is not used at all yet: https://github.com/clcollins/ocm-container/blob/golang/pkg/ocm/ocm.go ), or move it into the internal container and process it via bash, which we do a little of, but is really messy and makes startup take longer.

A lot of the ocm stuff is cribbing from osdctl, which is unfortunate. We really should try to get @AlexVulaj's ocm-common package stuff off the ground, if we can. There's too much code duplication here.

Finally, we also want to consider startup time - whatever we do here, we need to be really cognizant about how many calls we make to external services and external latency. One of the big complaints I hear from folks who choose not to adopt ocm-container is the startup time, and they're not wrong.

We should look at the minimum calls we need to make for any given cluster, both internal and external, make sure all required calls to get started are as concurrent as possible, and any subsequent data we need is called as needed (automatically, of course, so at least it feels like what you're going for here).

from ocm-container.

ocm backplane login shows a list of namespaces associated with the MC or Hive shard if we login with the --manager flag.
Maybe we can co-ordinate with those lovely folks to set those NSes as env vars (if that doesn't already happen) so everyone can benefit from this.

from ocm-container.