Do not fall back to anonymous when the /gvfs/config probe is indeterminate

[tyrielv]

What this fixes

A mount can end up permanently unauthenticated, and only a remount clears it.

GitAuthentication.TryInitializeAndQueryGVFSConfig probes /gvfs/config without
credentials. The probe has three outcomes, but the code only handled two:

Probe outcome	Meaning	Old behavior
200	Server allows anonymous access	IsAnonymous = true ✔
401	Credentials required	IsAnonymous = false ✔
timeout / 5xx / socket error	Unknown	IsAnonymous left at its default true ✘

The third case is indeterminate — it says nothing about authentication. Leaving
IsAnonymous at its true default silently downgrades the process to anonymous.

Why it never recovers

HttpRequestor.SendRequest short-circuits on IsAnonymous:

if (!this.authentication.IsAnonymous &&
    !this.authentication.TryGetCredentials(this.Tracer, out authString, out errorMessage))

So while IsAnonymous is true:

1. No Authorization header is sent, and TryGetCredentials is never called —
   git credential fill never runs, so no credential is ever fetched.
2. The Azure DevOps cache server answers with 400 and the body
   A valid Basic Authorization header is required.
3. A 400 is not retryable, so RetryWrapper aborts immediately.
4. RejectCredentials is a no-op, because its guard requires a non-null cached
   credential and none was ever cached.
5. MarkInitialized() already ran, so TryInitializeAndQueryGVFSConfig throws
   InvalidOperationException("Already initialized") if called again — the probe
   never re-runs.

Every recovery path is closed. The state persists for the life of the process.

User impact

Mount does not fail on this, because when a cache server is configured
InProcessMount deliberately continues ("Mount will proceed with fallback cache
server"). The repo mounts and looks healthy, but cannot download objects or blob
sizes. Directory enumeration fails with SizesUnavailableException, so
StartDirectoryEnumerationAsyncHandler returns an error and git reports tracked
files as deleted. Each enumeration retries and fails identically, flooding the
mount log.

Observed on a large enlistment: the config query timed out at mount, then ~35,000
auth errors and ~29,600 SizesUnavailableException in roughly one hour, with the
mount log growing past 70 MB. git status showed millions of phantom deletions.
Zero TryGetCredential events appeared in the entire log, while a separate
gvfs prefetch process authenticated normally against the same repo at the same
time — the classic signature of the process being stuck anonymous. Remounting
fixed it immediately.

The fix

Anonymous access becomes an affirmative determination: it requires a successful
unauthenticated probe.

• IsAnonymous now defaults to false.
• The indeterminate branch sets IsAnonymous = false explicitly and says so in
  the warning it traces.

If the server really does allow anonymous access, it ignores the Authorization
header GVFS sends after an indeterminate probe. The failure mode is now a
possible credential prompt instead of a mount that cannot serve files.

The default flip also closes a related gap: a request issued before initialization
completes previously went out anonymous. It now goes through TryGetCredentials,
which already waits on initializationComplete.

Not a 2.0 regression

v1.0.26098.1 has the same !IsAnonymous && TryGetCredentials(...) short-circuit
in SendRequest and the same hasCacheServer fallback in mount, and its
indeterminate branch also never assigns IsAnonymous. 1.0 reaches the identical
stuck-anonymous state. This targets vnext rather than master, because it
changes behavior on the authentication path for a long-standing defect rather than
repairing something 2.0 broke.

Known tradeoff (reviewer input welcome)

After an indeterminate probe, a genuinely anonymous server is now latched into requiring credentials for the life of the process, because MarkInitialized prevents a re-probe. A server that permits anonymous access simply ignores the Authorization header, so the real exposure is narrow: an anonymous repo, with no cached credential, after a transient probe failure — which could newly prompt via GCM.

Tests

GitAuthenticationTests — 6 tests covering all three probe outcomes plus the probe's own anonymity:

• InitialConfigProbeIsSentWithoutCredentials — the regression test for the bug above. Mirrors SendRequest's credential gate exactly (forceAnonymous || IsAnonymous) and asserts no credential is requested during the probe. InitializationWaitTimeoutMs is lowered to 500 ms so a regression fails fast instead of hanging the suite.
• AuthIsNotAnonymousBeforeInitialization — pins the new default.
• IndeterminateConfigProbeDoesNotLeaveAuthAnonymous — five real [TestCase(...)] rows (RequestTimeout, InternalServerError, ServiceUnavailable, BadRequest, and no HTTP response) so each status reports independently.
• IndeterminateConfigProbeStillAuthenticatesLaterRequests — credentials remain obtainable afterward.
• AnonymousConfigProbeSuccessLeavesAuthAnonymous, UnauthorizedConfigProbeRequiresAuthentication — guards against over-correcting.

Mutation testing, corrected. The original description claimed each half of the fix independently failed three tests. That was wrong — it reflected a combined revert. Re-run per half:

Mutation	Result
Remove forceAnonymous: true from the probe	fails InitialConfigProbeIsSentWithoutCredentials
Revert IsAnonymous default to true	fails AuthIsNotAnonymousBeforeInitialization (1 test, not 3)
Delete the explicit IsAnonymous = false on the indeterminate branch	fails nothing

The third result is expected: with the default now false, that assignment cannot change behavior. It is kept as defensive symmetry so each branch states its own outcome, and is commented as such.

Full unit suite: 948 tests, 0 failed (11 pre-existing ignored). StyleCop clean.

Why no functional test

The repro needs /gvfs/config to fail transiently while the cache-server path stays reachable. The functional suite clones from a live server and has no HTTP fault-injection seam, and the config endpoint URL derives from the same RepoUrl as object downloads, so the two cannot be failed independently. A true end-to-end unit test is also not yet possible here: HttpRequestor has no HttpMessageHandler seam on vnext (#2082 adds one). The new test therefore mirrors the production gate rather than driving SendRequest directly.