Add GCS signed URL support

[l1nxy]

Which issue does this PR close?

Closes #5233.

Rationale for this change

Adding support for GCS Signed URL generation.

What changes are included in this PR?

Are there any user-facing changes?

[l1nxy]

@tustvold Hi, I have completed the first version of GCP signed URL generation. Could you please take some time to review it? and then i can update the code gradually.
Regarding the credential structure, I think we need to add the client email field. This is because the signed URL generation requires the client email, not just the sign blob method. Even when generating a signed URL with an HMAC key, we still need the client email to create credentials with scope, the code example showed.

https://github.com/GoogleCloudPlatform/python-docs-samples/blob/6e591bec774bf0f3bf53864146f24028b98ac8df/storage/signed_urls/generate_signed_urls.py#L63-L65

next, i will add test for the sign blob and add code for using HAMC key to generating signed URL.

[tustvold]

Sorry for the delay in reviewing this, I wonder if instead of modifying GcpCredential which is a breaking change, we could introduce a GcpSigningCredential with something like

struct GcpSigningCredential {
    credential: GcpCredential,
    email: String,
}

This could then have a separate CredentialProvider<GcpSigningCredential>

[l1nxy]

I completely agree with you. However, a question arises: if I add a new credential type, will all implementations for TokenProvider need to be rewritten for GcpSigningCredential? This is because it involves additional operations to retrieve the client's email address. I am wondering if this would be acceptable.

[tustvold]

I would think you could use composition to avoid code duplication, with the GcpSigningCredential implementation calling through to the GcpCredential implementation

[s-i-l-k-e]

@l1nxy how is this going? Let me know if there is anything I can do to help -- would love to use this!

[l1nxy]

@l1nxy how is this going? Let me know if there is anything I can do to help -- would love to use this!

Apologies for the delayed update. I have been busy and unable to dedicate time to this. If you would like to proceed, feel free to do so, and I will close the pr.

[l1nxy]

@s-i-l-k-e Hi, I have time now and will continue working on this.

[l1nxy]

@tustvold Hi, sorry for the delayed update, i have a question and hope you can help me. my question is which part modification will cause a breaking change, can i add GcpSigningCredential provider to GoogleCloudStorageBuilder and GoogleStorageConfig?

[tustvold]

So long as you don't change an existing public API it won't be a breaking change. So you could add additional fields or new methods, but not change existing ones

[l1nxy]

@tustvold Hi, I made changes to the sign URL implementation by adding a GcpSigningCredential Provider. There are some changes that I'm unsure about. The ServiceAccountCredentials now includes the Clone trait because I cannot construct both GcpCredentialProvider and GcpSigningCredentialProvider using just one ServiceAccountCredentials instance simultaneously.

Thank you for your patience and help.

[l1nxy]

@tustvold Hi, I tested it using my GCP account. The ServiceAccount approach yielded correct results, but testing the email from the meta server was not done. Perhaps adding more unit tests or addressing some code issues. maybe i can add sign by HMAC key.

the test result is:

[tustvold]

This is looking really nice, I took the liberty of pushing some relatively minor API tweaks. I'll test this out tomorrow, and assuming that all works get it merged

[tustvold]

This prevents the ring types from leaking into the public API, whilst still avoiding needing to parse the RSA key for every sign request

[tustvold]

Moving this into ServiceAccountKey avoids doing this multiple times

[tustvold]

I've tested this and it appears to be working correctly 🎉

Thank you for this, epic work

[alamb]

Thank you @l1nxy and @tustvold -- this is a very nice feature