Fix bearer token invalidation bug by calling AddResponses() twice on 401 errors

[iain-macdonald]

Issue #, if available:
#686

Description of changes:
There's a pretty detailed description of the bug that this PR fixes at #686. This fix addresses the first sentence of the second paragraph there:

However, the soci-snapshotter code that provides HTTP Responses to the authorizer only ever provides the most recent HTTP Response, so the logic above is never exercised. Instead, it always hits the n == 1 condition in invalidAuthorization.

Instead of just calling AddResponses() with the one response, this PR changes that logic to provide the same 401 response twice to AddResponses() to force invalidation of the expired token and then adds a second call to AddResponses() with just once 401 response to fetch a fresh bearer token before proceeding to retry fetching resources from the remote registry.

Testing performed:
We have been using this fix in production at BuildBuddy to stream public container images from remote registries without incident:

Kern also kindly offered to add an integration test for this bug in #686.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[sparr]

* 9958f9a "Fix bearer token invalidation bug by calling AddResponses() twice on 401 errors" ... FAIL
- FAIL - does not have a valid DCO

Could you amend this commit to include a signoff? git commit -s will do so automatically.

[iain-macdonald]

Oh shoot, sorry about that. Just added one, confirmed it works with make check and re-pushed.

[Kern--]

Thank you!

[sparr]

Created blocked issue to fix this when the commented upstream PRs are released

[sparr]

For future reference, if you put "closes" or "fixes" or a few other key words before the issue # in the PR description, the issue will get closed when the PR is merged. https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword