…ary conditions

… 'defaultMaxAuthAttempts' repeated 401 responses

…tistage helper in auth_test.go

The DoWithAuth() method of the Client structure in our "lfsapi" package
calls the doWithAuth() method in a loop, and each time it passes its
"req" parameter, which is a Request structure from the "http" package
of the Go standard library.  The doWithAuth() method then passes this
Request structure to other methods, which may modify it to add or remove
an Authorization header.

In a prior commit in this PR we added a comment to the DoWithAuth()
method, following a suggestion from the initial review of this PR:

  git-lfs#6018 (review)

The comment states that the doWithAuth() method will always remove the
Authorization header from the Request structure if a 401 Unauthorized
status code was returned in response to the HTTP request, and so the
DoWithAuth() method should never find a non-empty Authorization header
after the doWithAuth() method has returned.

This is incorrect, however.  Further, it contradicts a second comment
that we proposed during another review of this PR.  In that review
we suggested this other comment should be included in the
TestDoWithAuthNoRetryOn401WhenAuthHeaderPresent() test function,
since we introduced that function in a previous commit in this PR:

  git-lfs#6018 (comment)

To resolve these problems we now add a lightly revised version of the
second comment to the TestDoWithAuthNoRetryOn401WhenAuthHeaderPresent()
test function, and correct the comment in the DoWithAuth() method so
that comment better reflects the actual expected behaviour of the
doWithAuth() method, which we describe in more detail below.

The doWithAuth() method invokes the getCreds() method, which uses
the requestHasAuth() function to check whether the Request structure
already has a defined Authorization method, and if so, returns a
CredentialHelperWrapper structure from our "creds" package with
a nil value in its Creds element.

The doWithAuth() method then invokes the doWithCreds() method to actually
perform the HTTP request.  If that method returns an error, the doWithAuth()
method checks whether it was due to a 401 status code in the response by
calling the IsAuthError() function from our "errors" package.  Should that
evaluate to "true", the doWithAuth() method then checks whether the Creds
element of the CredentialHelperWrapper structure returned by the getCreds()
method is nil, and only removes the Authorization header from the Request
structure if the Creds element is nil.

Therefore if the DoWithAuth() method is passed a Request structure with
a defined Authorization header, that header will not be removed by the
doWithAuth() method even if a 401 status code is received, and so the
DoWithAuth() method may find a non-empty Authorization header following
its call to the doWithAuth() method.

In prior commits in this PR we added several new test functions to our
"lfsapi" package to verify the behaviour of the DoWithAuth() method
of that package's Client structure.

These new functions include the TestDoWithAuthRetryLimitExceeded()
function and the TestDoWithAuthMultistageRetryLimitExceeded() function,
both of which check that the DoWithAuth() method now limits the number
of HTTP requests it will make if each request receives a 401 Unauthorized
status code in its response.

Both test functions follow a similar design as the existing
TestDoWithAuthApprove() function.  That older test function ends with a
check of the access mode which has been cached for the endpoint URL
associated with the HTTP requests made by the DoWithAuth() method, as
we expect that after the first 401 status code response is received,
this mode will be set to the BasicAccess mode from our "creds" package
to reflect that HTTP Basic Authentication should be used with all
subsequent requests.

Although our new TestDoWithAuthRetryLimitExceeded() function also ends
with a check of the cached access mode, this is not yet the case for
the TestDoWithAuthMultistageRetryLimitExceeded() function, so we add
that check now.

We also take the opportunity to simplify all of the access mode assertion
checks we make, which at present explicitly pass structure pointers
as the receiver parameters of the Mode() method of the Access structure
from our "creds" package.  While this method is defined with a pointer
receiver, it is not necessary to explicitly generate these pointers
because Go automatically does so as a convenience feature of the language:

  https://go.dev/tour/methods/6

The use of explicit pointer receivers for the Mode() method calls in our
test functions dates from commit 6d29072
in PR git-lfs#3941, when the Access structure was first moved into our "creds"
package.

In subsequent commits in this PR we intend to add new tests to validate
the changes we made to the Git LFS client in prior commits of this PR.
We plan to add these tests to both the "t/t-askpass.sh" and the
"t/t-credentials.sh" scripts in our shell test suite.

Before we add our new tests, we first update the existing "credentials
with useHttpPath, with wrong password" test in the "t/t-credentials.sh"
script, and add a similar test to the "t/t-askpass.sh" script, which
at present does not contain a test with an invalid set of credentials.
We will then be able to use these tests as templates for the additional
tests we expect to add in future commits.

First, we revise the "credentials with useHttpPath, with wrong password"
test to correct a check which at present will always trivially succeed.
After the test runs the "git push" command, it attempts to confirm that
the command failed to push a Git LFS object by checking that the command
did not output a final progress message stating that the object was
uploaded.  To verify the lack of this message, the test uses the -c option
of the grep(1) command and then checks that the returned value is zero.

When the original version of this test was first introduced in commit
69aee53 of PR git-lfs#561, the "grep" command
searched for the pattern "(1 of 1 files)" in the output of the "git push"
command, which was a valid check given the format of the Git LFS client's
progress messages at the time.

We then revised the format of the client's progress messages in commit
db4e3b2 of PR git-lfs#2811, and updated many of
the "grep" commands in our test suite to reflect the new format at the
same time.  Most of these alterations were made correctly, but in the
"credentials with useHttpPath, with wrong password" test the "grep"
command's pattern was changed to "Uploading LFS objects: 100% (1/1), 0 B".

Even if the "git push" command in the test were to unexpectedly succeed,
the trailing "0 B" portion of this pattern would still not match any
lines in the command's output, since the size of the test Git LFS object
to be pushed is actually one byte.  Thus this check will always pass,
regardless of the success or failure of the "git push" command.

To address this problem we simply remove the trailing portion of the
pattern, as we only need to confirm that the "git push" command's output
does not match the pattern "100% (1/1)".

We then add another, final check to the test which uses a different
technique to verify that the "git push" command did not upload a Git LFS
object.  Since we have already computed the OID of the object, we can
call our refute_server_object() test assertion function to confirm that
the object does not exist on the Git LFS remote.  This is a more direct
and less fragile method of checking the behaviour of the "git push"
command than parsing its output messages, and should help avoid any
future regressions of the type we have fixed in this commit.

As well as making these changes to the "credentials with useHttpPath,
with wrong password" test, we also add several new checks which use
"grep" commands to ascertain that HTTP authorization errors occurred
during the "git push" command.  Specifically, we check that the client
output two error messages, one after its request to the Git LFS lock
verification API endpoint received a 403 status code response, and
another after the client's request to the Git LFS Batch API endpoint
received a 403 status code response.

While adding these extra checks we also adjust the whitespace in the
test, and we drop an "echo" statement whose value is minimal, even for
debugging purposes.

Finally, we replicate portions of the design of this test to create a
new "askpass: push with core.askPass and wrong password" test in our
"t/t-askpass.sh" script.  This test establishes the same conditions as
those from the existing "askpass: push with core.askPass" test, except
that we set the LFS_ASKPASS_PASSWORD environment variable to contain
an invalid password.

As in our revised "credentials with useHttpPath, with wrong password"
test, our new "askpass: push with core.askPass and wrong password" test
then verifies the "git push" command made with the invalid credentials
did not upload a Git LFS object, and that two 403 status code responses
were received, one from the lock verification API endpoint and one from
the Batch API endpoint.

In prior commits in this PR we revised the DoWithAuth() method of the
Client structure in our "lfsapi" package so that it should no longer
enter an infinite loop if a Git LFS API implementation repeatedly
responds to requests with a 401 Unauthorized status code.

To help verify that these changes are effective, we now add a pair of
tests to our shell test suite, one in the "t/t-askpass.sh" script and
one in the "t/t-credentials.sh" script.  We base the design of these
tests on the "askpass: push with core.askPass and wrong password" test,
which we added in a previous commit in this PR, and the "credentials with
useHttpPath, with wrong password" test, which we updated in the same
previous commit.

To simulate a Git LFS API implementation which always responds with a
401 status code, we make a small enhancement to the skipIfBadAuth()
function in our "lfstest-gitserver" test utility.  This function
validates the credentials provided by the client in its request headers
and returns "false" if they match the expected values for the current
test repository, which allows the request to proceed.

Otherwise, if the credentials provided by the client are not the expected
ones, then the skipIfBadAuth() function returns "true" after first setting
the response's status code to 403.  When the anonymous function which
handles the default HTTP route receives the "true" return value from the
skipIfBadAuth() function it then curtails all subsequent request handling.

Because we require that the "lfstest-gitserver" utility simulate a server
which incorrectly returns a 401 status code instead of a 403 status code
when presented with invalid credentials, we alter the skipIfBadAuth()
function so the status code it sets in the HTTP response depends on the
name of the test repository in the request URL.  If the repository name
ends with the suffix "-401-unauth", the response to a request with invalid
credentials will contain a 401 status code instead of a 403 status code.

We then add "askpass: push with core.askPass and wrong password and 401
response" and "credentials with useHttpPath, with wrong password and
401 response" tests to the "t/t-askpass.sh" and "t/t-credentials.sh"
scripts, respectively.

These tests closely resemble the tests we added to the same scripts in a
previous commit in this PR.  However, they append the suffix "-401-unauth"
to the names of their repositories, and then verify that an appropriate
number of requests are recorded in the trace log of a "git push" command.
The tests also check that the command outputs an error message stating
that the limit on attempts to request authentication was reached.

Further, these tests implicitly confirm that our changes to the "lfsapi"
package prevent the DoWithAuth() method from entering an endless loop,
since if that were to occur, the tests would never complete.

We include comments in both tests which explain why we check that the
Git LFS client gathered the necessary credentials from the local
configuration only five times, rather than either three or six times,
as we might expect given that the current value of the
defaultMaxAuthAttempts variable in the "lfsapi" package is three.

First, Git LFS client should make two sets of requests during the
"git push" command, one set to the Locking API and another to the Batch
API.  Only the latter request must succeed in order for the client
to upload Git LFS objects; the former request is allowed to fail.  The
"lfstest-gitserver" utility will return 401 status codes to both types
of request, so a total of six requests are made, three to each API.

Second, the client will cache the access mode required by the Git LFS
remote endpoint after the first request is made to the Locking API,
and this cached data applies to the Batch API requests as well.
(Specifically, we retain the access mode in the urlAccess map element
of an endpointGitFinder structure, which is stored in the Endpoints
element of the Client structure of our "lfsapi" package.)

The initial request to the Locking API is made without an Authorization
header, and so no credentials are retrieved from the local configuration
for this request.  In our current version of the DoWithAuth() method we
count this initial request toward the total number of requests, so only
two requests with Authorization headers are made to the Locking API.

All requests to the Batch API, however, are made with Authorization
headers, because the initial request reads the cached access mode for
the Git LFS endpoint (which comprises both APIs) and therefore retrieves
credentials from the local configuration, as do both of the subsequent
requests.

This explains why our new tests check that the "git push" command
retrieved credentials from the local configuration five times and not
six.  Note that we anticipate that we will further refine the behaviour
of the DoWithAuth() method in a subsequent commit in this PR so that
requests without an Authorization header are not counted towards the
total number of attempts to request authentication.

In prior commits in this PR we revised the DoWithAuth() method of the
Client structure in our "lfsapi" package so that it should no longer
enter an infinite loop if a Git LFS API implementation repeatedly
responds to requests with a 401 Unauthorized status code.

To help verify that these changes are effective, we now add a test to
our "t/t-credentials.sh" shell test script.  This test is similar to the
existing "credentials can authenticate with multistage auth" test, which
was introduced along with our support for multi-stage authentication
schemes in PR git-lfs#5803.  Both the existing test and our new test make use
of the example "Multistage" authentication scheme used in our shell
test suite, which also first appeared in PR git-lfs#5803.

Our new test simulates a Git credential helper that is misconfigured or
broken in such a way that after a certain stage, it begins to always
return the same credentials and state.  To establish this intentional
misconfiguration we simply create a credential record file for our
"git-credential-lfstest" utility that contains two entries, one to
define the transition from the initial stage to the "state1" stage,
and another to define a self-referential transition from the "state1"
stage to the same "state1" stage.

Note that the "git-credential-lfstest" utility searches for a matching
entry in its credential record files in a sequential fashion, and that
entries with an empty fourth field (the "MATCH" field) are considered to
match against all states.  As a result, we must place the entry for the
transition from the initial stage to the "state1" stage at the end of
the credential record file, or else it would always match the current
stage.

To help clarify this detail of our test's setup steps we include a
comment which explains why the entry for the first transition must appear
last in the file.  We also take the opportunity to add similar comments
to the two existing tests in the "t/t-credential.sh" script that create
credential record files for multi-stage authentication, as they likewise
place the entry for their first transitions at the end of these files.

(As well, we slightly adjust the whitespace formatting of the existing
"credentials can authenticate with multistage auth" test so that it more
closely resembles our new "credentials with multistage auth loop fails"
test, as well as that of another multi-stage authentication test we expect
to introduce in a subsequent commit in this PR.)

After our new test establishes its misconfigured credential record file,
it performs a "git push" command and then performs the same set of checks
as are found in the "credentials with useHttpPath, with wrong password
and 401 response" test that we added in a prior commit in this PR, plus
one additional check specific to multi-stage authentication.

As we described in that previous commit, we expect the Git LFS client to
make two sets of requests during the "git push" command, one set to the
Locking API and another to the Batch API.  The initial request to the
Locking API is made without an Authorization header, and so no credentials
are retrieved from the local configuration for this request.

Because a 401 status code is received after the initial request, the
client then retrieves the first stage's credential and state from the
"git-credential-lfstest" helper and makes a second request, which also
receives a 401 status code response.  The client then retrieves the next
stage's credential and state from the helper, but due to our intentional
misconfiguration, these are the same as for the first state.

Our "lfstest-gitserver" test utility's skipIfBadAuth() function, which
determines whether to accept or reject the credentials presented in
a request's Authorization header, handles our example "Multistage"
authentication scheme by checking whether the credentials match either
the value "cred1" or the value "cred2".  The "cred2" credential value
will result in the function returning "false" and accepting the
credential, while the "cred1" value causes the function to return "true"
and the utility to respond with a 401 status code.

Since the client's second request to the Locking API also contains the
"cred1" credential, it again receives a 401 status code, which due to the
revisions we made to the DoWithAuth() method in prior commits in this PR
should cause the client to exit from the method and report that the
Locking API is not supported by the Git LFS endpoint.

We then expect the client to make an initial request to the Batch API,
but unlike the first request to the Locking API, an Authorization header
will be included because the access mode required by the Git LFS endpoint
has been cached by the requests to the Locking API.  When this request
receives a 401 status code response, it should then be retried two more
times before the DoWithAuth() method reports an error and exits.

This expected sequence of events explains why our new test checks that
the "git push" command retrieved credentials five times rather than six,
and why the test checks for five instances of the "cred1" credential in
an Authorization header and not six.

Note that we anticipate that we will further refine the behaviour of the
DoWithAuth() method in a subsequent commit in this PR so that requests
without an Authorization header are not counted towards the total number
of attempts to request authentication.

In prior commits in this PR we revised the DoWithAuth() method of the
Client structure in our "lfsapi" package so that it should no longer
enter an infinite loop if a Git LFS API implementation repeatedly
responds to requests with a 401 Unauthorized status code.  The method
now returns an error with the message "too many authentication attempts"
after a maximum of three requests receive 401 status code responses.

This error message is not always reported to the user, however, since
certain requests the client makes are considered to be non-critical.
In particular, various Git LFS commands start by making requests to
the Locking API of the remote Git LFS endpoint, but Git LFS services are
not required to implement that API.  If these requests fail, the client
just reports that the remote does not support the Locking API and then
proceeds to perform the given command.

In previous commits in this PR we have added several new tests to our
shell test suite which exercise the DoWithAuth() method under conditions
in which it now returns after making the maximum allowed number of
requests.

These tests can directly verify that the "too many authentication
attempts" error is returned by the DoWithAuth() method when all requests
to the Batch API receive 401 status code responses, because the client
reports the error's message to the user.

However, our tests can at present only indirectly verify that the same
error is returned by the DoWithAuth() method when all requests to the
Locking API receive 401 status code responses, since the error's message
is never reported to the user.  Instead, our tests count the number of
times certain trace log messages are output by the client and confirm
that these totals match what is expected if both requests to the Locking
API and requests to the Batch API repeatedly receive 401 status code
responses.

To allow our tests to more easily check that requests to both APIs
are treated equally under these conditions, we revise the DoWithAuth()
method so that when the GIT_TRACE environment variable is set to a value
considered "true", the method now outputs a "too many authentication
attempts" trace log message just before it returns an error with that
message.

We then update the relevant tests in our shell test suite to check for
two appearances of this message in the trace logs from the "git push"
commands they execute, since each such command should make requests to
both the Locking API and the Batch API, which in both cases should result
in the same error condition and message.

In prior commits in this PR we revised the DoWithAuth() method of the
Client structure in our "lfsapi" package so that it should no longer
enter an infinite loop if a Git LFS API implementation repeatedly
responds to requests with a 401 Unauthorized status code.  We have also
added tests which demonstrate that our changes to the DoWithAuth() method
are effective, including when a server only returns 401 status codes.

However, a misbehaving server is not the only condition which might
cause the DoWithAuth() method to perform the maximum allowed number of
requests without successfully authenticating or being rejected.  In
PR git-lfs#5803 we introduced support for multi-stage authentication, in which
a Git credential helper returns a series of credentials and states,
and Git LFS client makes a request for each state using the supplied
credentials.  The final state is expected to complete the authentication
sequence and either be accepted or rejected.

We have already added tests in previous commits in this PR which simulate
a broken or misconfigured credential helper that never returns the final
state in a multi-stage authentication sequence, and instead keeps looping
through the intermediate states.  Both the new "credentials with
multistage auth loop fails" test in our "t/t-credentials.sh" shell script
and the new TestDoWithAuthMultistageRetryLimitExceeded() function in our
Go test suite simulate a credential helper which never advances past an
intermediate authentication state.  These tests demonstrate that our
changes to the DoWithAuth() method ensure it will return after making the
maximum allowed number of requests, even if a multi-stage authentication
sequence is not complete.

This was the intended behaviour of the DoWithAuth() method and the other
Client structure methods at the time when PR git-lfs#5803 was developed.  In
commit 6783078 of that PR we introduced
a "count" variable to the DoWithAuth() method, which the method then
passed to the doWithAuth() method as a pointer.  The doWithAuth() method
incremented the "count" variable after making a multi-stage authentication
request, unless the maximum number of permitted requests had been made,
in which case it was supposed to report that the request was rejected.

The stated intent of this design was "to avoid a credential helper getting
stuck in an infinite loop if it keeps handing back the same credentials",
per the description in commit 6783078.

Unfortunately, this implementation did not work as expected because the
DoWithAuth() method called itself recusively if the current request
received a 401 status code response, and because each invocation of the
method would instantiate a new "count" variable with a zero value.
Thus every time the doWithAuth() method was called it could only ever
increase the variable's value to one, and so it would never find that
the maximum number of allowed requests had been made.

Technically, as we noted in a comment on this PR, a rare combination of
HTTP redirections and 401 status code responses could result in the
"count" variable being incremented past one.  With a sufficient number of
redirections the "count" variable could reach the maximum request limit
and the doWithAuth() method would then inform the credential helper that
the current credentials should be rejected.  However, because the
doWithAuth() method still returned an error indicating that the response
to the most-recent request contained a 401 status code, the DoWithAuth()
method would call itself recursively and the Git LFS client would enter
an infinite loop:

  git-lfs#6018 (comment)

The revisions we have made to the DoWithAuth() and doWithAuth() methods
in this PR should resolve the problems described above and ensure that
misconfigured multi-stage authentication sequences will not cause the
Git LFS client to repeat the same requests without ceasing.

Despite these changes, the client may still exhibit unintended and
unexpected behaviour if a credential helper is configured with a valid
multi-stage authentication sequence, but the number of stages in that
sequence exceeds the maximum number of requests we allow during an
authentication sequence.

In such a case, if the client makes several distinct types of requests
to the same Git LFS endpoint, then the client may improperly continue
the incomplete authentication sequence across the different types of
requests.

In particular, various Git LFS commands start by making requests to
the Locking API of the remote Git LFS endpoint, but Git LFS services are
not required to implement that API.  If these requests fail, the client
just reports that the remote does not support the Locking API and then
proceeds to perform the given command, which may require one or more
requests to the Batch API of the endpoint.

The client may therefore proceed through the initial stages of a long
multi-stage authentication sequence, making requests to the Locking API
of an endpoint, but reach the maximum number of requests we allow
before being either accepted or rejected because the sequence is not
yet complete.  However, if the client then begins to make requests
to the Batch API of the endpoint, it will continue where it left off
in the sequence, and may be able to successfully authenticate.

While that may appear to be beneficial, this behaviour was not our
intention when we added multi-stage authentication support in PR git-lfs#5803.
If we permit the client to continue multi-stage authentication across
different types of requests, the client may behave inconsistently for
users who have identical configurations except for the number of stages
in their authentication sequences.

We therefore update the DoWithAuth() method so that when it returns
after making the maximum allowed number of requests without successfully
authenticating or being rejected, it first resets the current state of
any multi-stage authentication sequence so that any subsequent requests
will restart the sequence from its first stage.  To reset the current
state we simply pass a "nil" parameter to the SetStateFields() method
of the CredentialHelperContext structure from our "creds" package, which
sets the structure's "state" field back to its post-initialization value
of "nil".

To confirm that our changes are effective we then add a new "credentials
with multistage auth above limit fails and resets" test to our
"t/t-credentials.sh" shell test script.  This test establishes a
four-stage authentication sequence by creating a credential record file
for our "git-credential-lfstest" utility that contains four entries,
each of which defines a transition from one stage of four to the next.

For this four-stage authentication sequence to be fully supported by
our "lfstest-gitserver" test utility, we have to modify its
skipIfBadAuth() function, which determines whether to accept or reject
the credentials presented in a request's Authorization header.

Since commit a3429c3 of PR git-lfs#5803, the
skipIfBadAuth() function handles our example "Multistage" authentication
scheme by checking whether the credentials match either the value
"cred1" or the value "cred2".  The "cred2" credential value will result
in the function returning "false" and accepting the credential, while
the "cred1" value causes the function to return "true" and the utility
to respond with a 401 status code.

Several of the existing tests in our "t/t-credentials.sh" script
depend on the "lfstest-gitserver" utility accepting the "cred2" value
in an Authorization header to complete a multi-stage authentication
sequence.  As our new test requires the utility to not accept the first
three of four credentials in a sequence, we alter the skipIfBadAuth()
function so that it expects the values in an Authorization header with
a "Multistage" scheme to match the pattern "cred<m>of<n>".

If a "Multistage" scheme credential matches this pattern and the "<m>"
and "<n>" values are equal, the skipIfBadAuth() function will return
"false", indicating that the credentials are valid; otherwise, it will
return "true" and cause the "lfstest-gitserver" utility to respond
to the request with a 401 status code.

We then update our existing tests in our "t/t-credentials.sh" script
so that they create credential record files whose entries follow the
revised pattern, e.g., "cred1of2" and "cred2of2".

Our new "credentials with multistage auth above limit fails and resets"
test, however, creates entries in its credential record file of the
form "cred1of4", "cred2of4", etc.  Because the defaultMaxAuthAttempts
variable in the "lfsapi" package is assigned a value of three, we allow
at most three requests during an authentication sequence.  By defining
a four-stage authentication sequence for our new test, we guarantee
that each distinct type of request made by a Git LFS command should
reach the three-request limit without successfully authenticating.

Like the other tests we have introduced in previous commits in this PR,
our new test establishes its credential record file and then runs a
"git push" command.  As we described in those commits, we expect the
Git LFS client to make two sets of requests during the "git push"
command, one set to the Locking API and another to the Batch API.

Because the initial request to the Locking API is made without an
Authorization header, we expect that no credentials will be retrieved
from the local configuration for this request.  The client should then
make two more requests to the Locking API, both with credentials,
before reaching the per-sequence limit of three requests.  The client
should then proceed to make three requests to the Batch API, all with
credentials, before again reaching the per-sequence limit.

This expected sequence of events explains why our new test checks that
the "git push" command retrieved credentials five times rather than six,
and why the test checks for two instances each of the "cred1of4" and
"cred2of4" credentials in Authorization headers, but for only one
instance of the "cred3of4" credential and none of the "cred4of4"
credential.

Note that we anticipate that we will further refine the behaviour of the
DoWithAuth() method in a subsequent commit in this PR so that requests
without an Authorization header are not counted towards the total number
of attempts to request authentication.

Further, note that our new test would fail without our change to the
DoWithAuth() method in this commit, because the Git LFS client would
successfully authenticate on its second request to the Batch API.
The client would send the "cred3of4" credential on its first request to
that API, and then send the "cred4of4" credential on its next request.

In prior commits in this PR we revised the DoWithAuth() method of the
Client structure in our "lfsapi" package so that it should no longer
enter an infinite loop if a Git LFS API implementation repeatedly
responds to requests with a 401 Unauthorized status code.  The method
now returns an error with the message "too many authentication attempts"
after a maximum of three requests receive 401 status code responses.

Because the defaultMaxAuthAttempts variable in the "lfsapi" package is
assigned a value of three, we currently allow at most three requests
during an authentication sequence.

As we have described in several of our previous commits, the Git LFS
client may make multiple sets of requests during a single command,
such as requests to the Locking API and then to the Batch API of a
given endpoint.

When the Git LFS client makes the first request to an endpoint's
Locking API, no access mode for the endpoint has yet been determined
(unless the user has explicitly configured an "lfs.<url>.access" option).
The client therefore sends a request without an Authorization header,
in case the endpoint does not require any credentials at all.

If the endpoint does require credentials, it will respond with a
401 Unauthorized status code.  The client will now cache the access
mode required for for the endpoint, and this cached data applies to
the Batch API requests as well.  (Specifically, we retain the access
mode in the urlAccess map element of an endpointGitFinder structure,
which is stored in the Endpoints element of the Client structure of
our "lfsapi" package.)

In our current version of the DoWithAuth() method we count the initial
request made without an Authorization header toward the total number of
attempts to request authentication.  This can result in inconsistent
behaviour if the endpoint requires a multi-stage authentication sequence
with the same number of stages as the maximum number of authentication
requests that we allow.

For example, if a three-stage authentication sequence is configured,
then the client will reach the request limit without completing the
sequence when making requests to the Locking API, but will complete
the sequence when making requests to the Batch API.

To avoid this inconsistency between types of requests, we revise the
DoWithAuth() method so that if no access mode has yet been determined
for the endpoint, the method increases the maximum number of requests it
will allow by one.

We then update some of our Go and shell tests to reflect this change by
incrementing the numbers of requests the tests expect to have been
performed by the client when it reaches the maximum number of allowed
requests following an initial request without an Authorization header.

We also adjust the comments in these shell tests to explain that the
initial request without an Authorization header is not counted towards
the maximum number of allowed requests for authentication, and
concomitantly, we increment the number of times the tests expect the
Git LFS client to retrieve credentials in order to make its requests.