feat: add expires_in and token_type to ServiceAccountJwtAccessCredentials

[vishwarajanand]

Fixing two issues here:

1. Returning type and expires_in with the token in case of JWT keys. ref: feat: add universe domain support to core, bigquery, storage, and pubsub google-cloud-php#6850 (comment)

2. Fixing lint issues with AccessToken.php:
   The lint check is complaining about retuning string|array in loadPhpsecPublicKey method (ref) and expects a string instead. I am not sure whether this is the best fix, but looks like __toString method (ref) is marked as public also returns a key. Throwing a TypeError if the key is array and not a string since thats consistent with an existing error in that case from here.

We confirmed that the access_token cannot have any other type and expires_in is usually ~3600 always. So, this change might be redundant, but IMHO its good to have.

BEGIN_COMMIT_OVERRIDE
feat: add expires_in and token_type to tokens from ServiceAccountJwtAccessCredentials (#513)
END_COMMIT_OVERRIDE

[bshaffer]

I think the best thing here would be to allow the method loadPhpsecPublicKey to return string or array, rather than throw a type error, which could be a breaking change.

[vishwarajanand]

@bshaffer this is not a breaking change because it's limited to a private function return type and the TypeError in the affected case would anyways be thrown from Firebase\JWT\Key class, here.

If we allow string|array, it will fail lint check because Firebase\JWT\Key::__construct(..) doesn't accept array and will throw a lint failure.

[bshaffer]

this is not a breaking change because it's limited to a private function

When throwing an exception, the visibility of the function isn't necessarily important since the exception can bubble up through to public functions

the TypeError in the affected case would anyways be thrown from Firebase\JWT\Key class

That's a good point

If we allow string|array, it will fail lint check

I see. I'd be curious to know 1. What caused the type to change (and suddenly trigger the lint error when it wasn't before) and 2. In what scenarios does phpseclib return a string here? This will help us make sure that throwing an exception is indeed the right option here (as opposed to say, excluding a version of phpseclib in our dependencies, or casting the string to array).

[vishwarajanand]

@bshaffer here are the answers:

1. What caused the type to change (and suddenly trigger the lint error when it wasn't before)
   It's because of a recent phpseclin release v3.0.35, relevant commit. toString() seems to have had a conscious (maybe I am not sure?) change which is breaking our lint. There is only one place where the AsymmetricKey::toString() is implemented and doesn't return string, and that's PublicKey::toString(), ref which returns a mixed.
2. throwing an exception is indeed the right option here (as opposed to say, excluding a version of phpseclib in our dependencies, or casting the string to array)
   Excluding versions likely wont help coz this will be visible in all future 3.0.35+ versions.
   Wrt Casting, I am not sure because its mixed so not sure of the array key, etc and this class is used in a lot of places.

I will raise this with phpseclib as well, in hope of a reply that maybe they also think this was unintended.

[vishwarajanand]

@bshaffer I have split this PR into 2 more PRs, listed in order of how they could be merged:

1. For fixing lint: fix: lint error from new phpseclib #517
2. For adding expires_in and token_type in Jwt: this PR
3. For deprecating phpseclibV2 classes: deprecate: remove support for phpseclib V2 #518

[bshaffer]

I'm calling this a feature since it adds functionality that previously wasn't there