Require authentication on permission policies when role-based authorization is disabled

[ramonsmits]

Fixes:

• API accepts requests without a valid token when authentication is enabled and role-based authorization is disabled #5986

Problem

When Authentication.Enabled is true and Authentication.RoleBasedAuthorizationEnabled is left at its default of false, the error, audit and monitoring instances accept requests without a bearer token, with an invalid token or with an expired token on every action that carries a permission policy. The request runs as if a signed-in user had sent it.

PermissionPolicyProvider chose between the role-checking policy and a shared allow-all policy by looking only at the RBAC setting. The allow-all policy has no authenticated-user requirement. The RequireAuthenticatedUser fallback policy does not help, because ASP.NET Core only applies it to endpoints without authorization metadata, and every controller action carries [Authorize(Policy = ...)].

Introduced in 6.18.0 by #5518. When that change broke the Should_reject_requests_* acceptance tests, the fixtures were switched to RBAC enabled, which removed the coverage for the default configuration.

Change

The provider now takes both settings into account:

• Authentication disabled: allow-all, and RBAC is ignored. This matches the documented master switch.
• Authentication enabled, RBAC disabled: every permission requires an authenticated user. This restores the behavior from before role-based access control was added, so requests without a valid token get a 401.
• Authentication and RBAC enabled: unchanged.

Supporting changes:

• The startup log line for authentication settings now includes the RBAC setting, so operators can see which authorization mode an instance runs in.
• The monitoring container health check now calls the anonymous root endpoint instead of /connection. The old target requires an authenticated user whenever authentication is enabled and only appeared to work because of this defect. The error and audit images already check anonymous routes.

Constraints

• Every controller action carries a permission policy, so those policies must enforce authentication themselves. The fallback policy cannot be relied on for them.
• [AllowAnonymous] routes are unaffected: the root endpoints, /api/configuration, the health endpoints and the audit-count route stay open as before.
• With RBAC disabled, callers that pass authentication hold every permission, which is what EffectivePermissions already reports to ServicePulse.

Verification

• New unit tests evaluate every permission through the real AddServiceControlAuthentication and AddServiceControlAuthorization registrations for each combination of the two settings. Against the previous provider, two of them fail, including anonymous callers being allowed every permission with authentication enabled and RBAC disabled.
• New When_authentication_is_enabled_without_role_based_authorization acceptance fixture on all three instances (2 tests each):
  • A request without a token to every route that is not [AllowAnonymous] gets 401. Against the previous provider, this test fails.
  • A valid token without roles is accepted.
• The existing When_authentication_is_enabled fixtures (RBAC enabled) also run the every-route test.
• An invalid, expired or wrong-audience token does not authenticate the caller, so it takes the same path as a request without a token. JWT validation does not depend on the RBAC setting, so the existing token tests run only with RBAC enabled.
• Checked cross-instance calls: scatter-gather and remote connection details forward the caller's Authorization header, and the remote probes target anonymous routes.