HttpRequestor: do not reject credentials on HTTP 400

[tyrielv]

Summary

GVFS erased a valid credential when an object-download response was HTTP 400, which
triggered a storm of Git Credential Manager popups.

Most 400s are not authentication failures. A present-but-expired or invalid
credential returns 401 (or 302, the Azure DevOps sign-in redirect). A
malformed request — for example a corrupt object SHA that produces an invalid
loose-object URL — returns a 400 that has nothing to do with credentials.
Rejecting credentials on every 400 erased good credentials.

There is one genuine exception, confirmed in the Azure DevOps cache-server
source: the cache server returns a 400 (not a 401) when the request carried no
parseable Basic Authorization header, with the body
"A valid Basic Authorization header is required.". That single 400 really does
mean "authentication required". microsoft/git's git-gvfs-helper maps the same
cache-server 400 to a 401 for this reason, and its own TODO says to confirm the
response body — which is exactly what this change does.

Change

• In HttpRequestor.SendRequest, the credential-rejection decision is now
  body-aware via ShouldRejectCredentials(HttpStatusCode, string responseBody):
  • 401 and 302 always reject credentials.
  • 400 rejects credentials only when the response body matches the cache
    server's auth-required message (case-insensitive substring).
  • Every other 400 (and 404 / 5xx / timeouts) does not reject credentials and
    flows through the generic, non-auth error path. 400 remains non-retryable
    (ShouldRetry never included it).
• The auth-required message is kept as a named constant
  (CacheServerAuthRequiredBadRequestMessage) that mirrors the cache server's own
  string (GvfsHttpHandler.PrepareContextAsync).

Why 400 is (almost) never an auth failure — but sometimes is

Verified against the Azure DevOps GVFS cache-server source and its L2 tests:

• No / unparseable Authorization header → 400 "A valid Basic Authorization header is required." — genuinely "auth required" (this is the case we still reject on).
• Present but bad / expired / unauthorized credential → 401 (cache server surfaces the /gvfs/auth result).
• Valid credential + corrupt object SHA → 400 "…Invalid ObjectId in the URI." — a request problem, not auth. This is the storm trigger; it must not erase the credential.
• Valid credential + missing object → 404.

The cache server's own L2 test asserts exactly this: no auth header → BadRequest
(400); bad PAT → Unauthorized (401).

Tests

GVFS.UnitTests/Http/HttpRequestorTests.cs:

• 401 and 302 reject credentials.
• 400 with the cache server's auth-required body rejects credentials (and the match
  is a case-insensitive substring).
• 400 with a non-auth body (e.g. "Invalid ObjectId in the URI") does not reject.
• 400 with no body does not reject.
• 404 / 500 / 408 do not reject.

All new tests pass (7/7); full unit-test suite passes.

[tyrielv]

Back to draft - git-gvfs-helper in microsoft/git also has the same conversion, so I probably just didn't repro the status 400 with bad credential correctly. This will need to be addressed some other way.