feat(staging): add staging config

[zeroshade]

Adds an undocumented environment variable DBC_USE_STAGING that when set to 1, true or TRUE will point dbc's default private URI to dbc-cdn-private-staging.columnar.tech instead of dbc-cdn-private.columnar.tech.

[amoeba]

I tested this out by running and getting:

$ DBC_USE_STAGING=1 go run ./cmd/dbc auth login
Opening https://auth-staging.columnar.tech/activate?user_code=GMBD-VKNH in your default web browser...
Authentication successful!

One nit and one question: Did we want setting DBC_USE_STAGING to also have dbc use the staging index for search/info/install? It doesn't appear to be from this PR. Happy to mark that as a follow-ons. At least auth works here.

[amoeba]

nit: Can we make these defaultOauthURI values the actual URI and then we don't have to concatenate a string later on like this?

mustParseURL("https://" + auth.DefaultOauthURI())},

Maybe there's a reason you had it separated out?

[zeroshade]

the IsColumnarPrivateRegistry function compares against url.URL.Host which doesn't contain the scheme. We also compare the host elsewhere which doesn't include the scheme, so it made more sense for the DefaultOauthURI to only be the host and not include the scheme so that I wouldn't have to reconstruct (or deconstruct) to perform the comparisons elsewhere with parsed URL objects.

Did we want setting DBC_USE_STAGING to also have dbc use the staging index for search/info/install? It doesn't appear to be from this PR. Happy to mark that as a follow-ons. At least auth works here.

It does force dbc to use the dbc-cdn-private-staging url for search/info/install of the private drivers. This doesn't implement adding the /staging/ prefix to the urls for the public registry, you're correct there. I think that's up for discussion I guess. Since we aren't dealing with auth stuff through there (i.e. we don't need to point at other URLs) we can use the built-in cloudfront cdn staging configs if we ever need to change the actual deployment configs I think.

[amoeba]

Thanks, makes sense. No need for a change here. I think later down the line we could think about how this env var interacts with our REGISTRY_URL override (or whatever it's called).