feat: Implement TrustBoundaries

[vverman]

This change includes trust boundaries for Service Accounts, Workload and Workforce Federation in the google auth nodejs library.

Impact This will allow clients who use the google auth library to also enable trust boundaries ensuring service accounts can access only those resources which are within the trust boundary. We use this design doc as reference for the code changes.

Testing Unit testing included for all clients who use trust boundaries.

[lsirac]

I think the current implementation is acceptable but can potentially be improved. @d-goog @nbayati would like to hear your thoughts:

1. Instead of each auth client subclass (like JWTClient, ComputeClient, BaseExternalAccountClient, etc.) implementing a full fetchTrustBoundary method as currently defined in the TrustBoundaryProvider interface, their primary role would be to provide the specific configuration data required for the trust boundary lookup. This mainly involves supplying the unique API endpoint URL relevant to that client type (e.g., the service account lookup URL for JWTClient or the dynamically determined workload/workforce pool URL for BaseExternalAccountClient). The core logic for actually performing the lookup (including caching, enablement checks, and the HTTP request via the common lookupTrustBoundary utility in trustboundary.ts) would be common and invoked centrally.

2. The invocation of the trust boundary data fetch should be managed at a higher, common level, likely within the base AuthClient class, as part of its token refresh lifecycle. Currently, each client subclass individually calls this.fetchTrustBoundary(...) after its specific access token refresh mechanism completes (e.g., in jwtclient.ts, computeclient.ts). My suggestion is to move this invocation into a shared method within AuthClient. After any subclass successfully refreshes its access token, this centralized method in AuthClient would then be responsible for initiating the trust boundary data fetch, using the endpoint information provided by the subclass (as per point 1) and the newly acquired access token.

This approach would mean individual auth clients are primarily responsible for "declaring" that they are "trust boundary supported" and give their trust boundary endpoint. The AuthClient base class, in conjunction with the existing lookupTrustBoundary utility, handles the "how and when" of fetching and managing the trust boundary data in a more centralized manner.