feat(gcs): allow setting a token directly

[jdockerty]

Which issue does this PR close?

Closes #4876

Rationale for this change

An OAuth2 token cannot be set directly at the moment, instead other mechanisms are required such as the credential or credential_path.

What changes are included in this PR?

Inclusion of a token within the GcsConfig and corresponding methods so that a bearer token is set within the signed requests to GCP.

Are there any user-facing changes?

Direct token being available as a option for authentication

[Xuanwo]

Hi, #4979 has been merged, we can continue this one now.

[Xuanwo]

scope will be DEFAULT_GCS_SCOPE if not set.

[jdockerty]

Thanks, I've altered this now.

I skimmed over that it was being set already with a default, I'll combine this with the direct String usage too. Much appreciated 👍

[Xuanwo]

scope must be valid, we can store as String directly.

[Xuanwo]

We don't need to change the logic here since load_token has already handled this.

[jdockerty]

Makes sense 👍

Do I understand rightly that the same is also true for sign_query? I.e. my addition here should also be removed.

opendal/core/src/services/gcs/core.rs

Lines 163 to 170 in 55fc762

	if let Some(token) = &self.token {
	req.headers_mut().remove(HOST);
	let header_value = format!("Bearer {}", token);
	req.headers_mut()
	.insert(header::AUTHORIZATION, header_value.parse().unwrap());
	return Ok(());
	}

I've added ☝️, but the sign_query is handled through load_credential and not load_token

[Xuanwo]

Oh, this part is a bit complex. Let me elaborate.

---

GCS's token-based authorization doesn't support signed queries. Signed queries involve credentials to build presigned URLs, similar to AWS S3. We can't build such presigned URLs using a token. So if users only set a token but not credentials, the signed query won't work.

However, I believe the changes here are the same, and we don't need to alter code sign_xxx. Just let load_xxx handle it.

[Xuanwo]

Great, thanks!