CosmosDB: AAD auth related fix

[milismsft]

Add the missing auth context when creating the barrier related requests.

[moderakh]

1. does the bug only impact certain consistency level?
   are Eventual and Session expected to work without this fix?

2. the PR code change relies on AuthorizationTokenType originalRequestTokenType = authorizationTokenProvider.getAuthorizationTokenType(); for inferring the token type. do we expect the original request and the barrier request to have different auth token types?
   why can't we rely on the request.authTokenType?

[milismsft]

1. yes, the Session and lower consistency are not affected by this issue.
2. see response in the code review comment.

[moderakh]

other than @j82w comment on the test and the following question, LGTM. Thanks Milis.

In the case of the AAD token, since it does get automatically refreshed in the background, we do want to make sure we reflect the latest value and not reuse some value that might not be current (an unlikely scenario since token refresh is at least 10 minutes before expiry but not impossible).

my question about above is that the background refresh should only refresh the token value. correct? not the token type?
why token type should change during a refresh?

do we expect the token type and authorization type to change in the lifetime of a single Cosmos Client?

[milismsft]

At this time we do not expect the token type to be changed within the same Cosmos Client.

The main reason we want to read the token type from the provider rather is to be consistent, since that is what we inherit from the CosmosClient and not some default value that might have been used unintentionally (see the create() method on the RxDocumentServiceRequest class). Later in the same function we use that provider to handle auth headers and we risk a mismatch which can result into a null pointer exception or some other error.

[milismsft]

/azp run java - cosmos - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).