Relates to docker#2

Signed-off-by: Djordje Lukic <djordje.lukic@docker.com>

The RFC 8414 §3.1 path-aware variant added in e3fed03 is a speculative
guess about where an authorization server *might* publish its metadata.
Several real-world deployments answer that URL with something other
than 404 (e.g. a gateway that returns 403 for unknown well-known
prefixes, or a 5xx from an upstream component) while still serving
valid metadata at the legacy 'append-to-issuer' URL.

Before this change, getAuthorizationServerMetadata short-circuited on
the first non-404 status with a hard error, even though further
candidates would have succeeded. That regressed every issuer with a
path component whose path-aware endpoint doesn't 404.

Probe semantics now:

  - 200 with a decodable body wins immediately.
  - Non-404 statuses, transport errors and JSON-decode failures are
    logged and the next candidate is tried.
  - If at least one candidate produced a non-404 status or a
    transport-level error and none returned 200, surface the most
    diagnostic failure so a misconfigured auth server is still visible.
  - If every candidate 404'd, fall back to default metadata exactly as
    before (legacy behaviour).

Covered by three new tests:

  - TestGetAuthorizationServerMetadata_NonFatalCandidateStatus: 403 on
    candidate #1, 200 on candidate docker#2 → success.
  - TestGetAuthorizationServerMetadata_AllUnreachableSurfacesError: every
    candidate 500s → error surfaced.
  - TestGetAuthorizationServerMetadata_All404FallsBackToDefaults:
    legacy behaviour preserved.