BuildWorkloadJWTSVIDClaims fix for real credential composer implementation

[enj]

TestBuildWorkloadJWTSVIDClaims/real_no-op_composer fails with the following error without this change:

rpc error: code = Internal desc = credentialcomposer(noop):
invalid workload JWTSVID attributes: failed to encode claims:
proto: invalid type: *jwt.NumericDate

Pull Request check list

• Commit conforms to CONTRIBUTING.md?
• Proper tests/regressions included?
• Documentation updated?

Affected functionality

Commands such as spire-server jwt mint (and their associated RPC APIs)

Description of change

json.Marshal the JWTSVIDAttributes.Claims before attempting to convert to structpb.Struct.

[azdagron]

Hey @enj! Thanks for expanding the test coverage and providing a fix. I think the proposed solution is pretty robust and probably just fine. I do wonder about paying the marshaling/unmarshalling cost for each svid minting (multiplied by the number of cred composers in the chain) but that probably is a very small fraction of the CPU spent on each RPC.

One option is to change the callers to not use these custom types. The only place this is called currently is by the credtemplate.Builder, which could trivially be changed to use sometimevar.Unix() on the fields that it is currently using jwt.NumericDate for.

Another option here would be change the credentialcomposer facade interface to take in structpb.Struct for the claims instead of map[string]interface{} so callers have worry about this concern instead. This has the added value that the loop that invokes credential composers no longer needs to do conversions in and out of structpb.Struct for each iteration.

[azdagron]

Thanks again @enj. After some thought, I think we'll take this as-is. I might get around to changing up the code to side step the problem but at any rate this is a solid fix and the increase in test coverage is 🦸 .