internal/resource: fix gs:// fetches in GCE without a service account

[bgilbert]

When running in GCE, we assumed that we should always perform authenticated GS fetches. However, these can fail if the VM is not associated with a service account, even if the object being fetched is publicly readable:

error while reading content from ...: metadata: GCE metadata "instance/service-accounts/default/token?scopes=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdevstorage.read_only" not defined

Query the VM's service account scopes first, and if that query fails (presumably because there is no service account), fall back to anonymous access.

[cgwalters]

I assume there's an externally-reported bug here, or did you find this yourself? Are you working on #1362 ?

[cgwalters]

This seems sane to me, but should we (also/instead) tell anyone who is using gs:// for unauthenticated access to instead access via https://? What's the advantage of going via gs:// ?

[bgilbert]

In the course of working on coreos/fedora-coreos-config#1717, I realized that we don't have kola tests for GCS, and while adding those I discovered that of course the feature doesn't completely work. I'm not working on #1362 per se, but note that that issue only covers running these tests in upstream CI; the FCOS release test suite will run them regardless. (Which is too late to prevent a bad Ignition release, but better than nothing.)

The advantage of gs:// is authenticated access, but it's legal for configs to use it for unauthenticated access as well, and configs might want to do so for consistency. (s3:// behaves similarly.) And in the unauthenticated case, we shouldn't fail provisioning solely because the instance was started without credentials.

[sohankunkerkar]

Tested this using gs://ignition-test-fixtures/resources/anonymous
LGTM