credentials: implement file-based JWT Call Credentials (part 1 for A97)

[dimpavloff]

Part one for grpc/proposal#492 (A97).
This is done in a new credentials/jwt package to provide file-based PerRPCCallCredentials. It can be used beyond XDS. The package handles token reloading, caching, and validation as per A97 .

There will be a separate PR which uses it in xds/bootstrap.

Whilst implementing the above, I considered credentials/oauth and credentials/xds packages instead of creating a new one. The former package has NewJWTAccessFromKey and jwtAccess which seem very relevant at first. However, I think the jwtAccess behaviour seems more tailored towards Google services. Also, the refresh, caching, and error behaviour for A97 is quite different than what's already there and therefore a separate implementation would have still made sense.
WRT credentials/xds, it could have been extended to both handle transport and call credentials. However, this is a bit at odds with A97 which says that the implementation should be non-XDS specific and, from reading between the lines, usable beyond XDS.
I think the current approach makes review easier but because of the similarities with the other two packages, it is a bit confusing to navigate. Please let me know whether the structure should change.

Relates to istio/istio#53532

RELEASE NOTES:

• credentials: Add credentials/jwt package providing file-based JWT PerRPCCredentials (A97).

[codecov]

Codecov Report

❌ Patch coverage is 94.65649% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.73%. Comparing base (dd718e4) to head (4336d04).
⚠️ Report is 71 commits behind head on master.

Files with missing lines	Patch %	Lines
credentials/jwt/token_file_call_creds.go	95.00%	3 Missing and 1 partial ⚠️
credentials/jwt/file_reader.go	94.11%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8431      +/-   ##
==========================================
- Coverage   82.27%   80.73%   -1.55%     
==========================================
  Files         414      415       +1     
  Lines       40424    40976     +552     
==========================================
- Hits        33259    33081     -178     
- Misses       5795     6220     +425     
- Partials     1370     1675     +305     

Files with missing lines	Coverage Δ
credentials/jwt/file_reader.go	94.11% <94.11%> (ø)
credentials/jwt/token_file_call_creds.go	95.00% <95.00%> (ø)

... and 262 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dimpavloff]

@dfawley hey 👋 Given you approved A97, would you mind having a cursory look at the PR to confirm if at least at a high level the approach looks good?

[eshitachandwani]

I will take a look at this , I need to go through the gRFC first.

[dfawley]

Sorry for the delay here.

@easwars would you be able to review this change? I think you have more background into some of the things than I do, like the bootstrap integration. Thank you!

[easwars]

Thank you for your contribution @dimpavloff. Yes, it would be nice if you can split this into smaller PRs. I will continue to use this PR to review the JWT call credentials implementation. If you can move the xDS implementation out to one or more PRs, I would greatly appreciate that and would be happy to review them as well.

[easwars]

Please only test the API surface. Relying on implementation internals in tests makes them brittle and would result in test changes when any changes to implementation is made.

[dimpavloff]

I assume you are referring to using a private field rather than obtaining mu specifically.
In general I agree -- white box tests may get fragile and break during a refactor. However, this test and the next couple of ones are about the caching behaviour -- it is meant to be transparent to the external API. If I don't make assertions about the private fields, the tests may pass trivially and become more flaky (e.g. when testing the backoff in the next test).
One alternative could be factoring out these behaviours out into a separate private struct with "public" functions which expose the same information. Given that it would require shifting the majority of the implementation into that struct, I'm not sure it is an improvement from the current approach.
Please do let me know your thoughts and if you have other suggestions.

[dimpavloff]

Thanks for the review @arjan-bal . Could you please take another look?

[arjan-bal]

Some minor comments and one pending unresolved comment about using strings.Cut while parsing the JWT.

[arjan-bal]

LGTM, thanks for the contribution!

[dimpavloff]

Great, thank you both for all the feedback! I'll tidy up the other PR soon