RANGER-5677: Plugin REST endpoints silently ignore supplied credentia…

[vyommani]

Problem

security="none" on the plugin download endpoints (gds, plugins/policies,
tags, roles, xusers) skipped Spring Security's whole filter chain for
exact URL matches, so Basic auth credentials were silently dropped and the
request was treated as anonymous. Because the pattern was a single-segment
wildcard (*), a trailing slash accidentally escaped the bypass and hit the
normal authenticated chain instead - so the same URL behaved differently
depending on a trailing slash:

GET .../download/dev_hive?... -u admin:pass -> 400 (creds dropped)
GET .../download/dev_hive/?... -u admin:pass -> 200 (creds processed)

On a Kerberized admin there was a second issue: RangerKRBAuthenticationFilter
forces a SPNEGO challenge on any request with no existing auth, regardless of
Spring Security's authorization rules - so even after fixing the URL matching,
anonymous requests were still rejected with 401 regardless of
ranger.admin.allow.unauthenticated.download.access.

Fix

1. security-applicationContext.xml - removed these 5 endpoints from
   security="none", added permitAll intercept-url entries instead, using
   ** so matching is slash-insensitive. permitAll only removes the
   authorization requirement, not authentication - credentials are still
   validated when present, and RangerBizUtil.failUnauthenticatedDownloadIfNotAllowed()
   remains the actual gatekeeper for anonymous access.
2. RangerKRBAuthenticationFilter.java - skip the forced SPNEGO challenge
   only when the URL is one of these 5 endpoints and no Authorization header
   is present. Requests that do present credentials (Negotiate or Basic) are
   unaffected.
3. Added unit tests for the new URL-matching and bypass logic.

services/grant/services/revoke share the same defect but are policy-mutating
endpoints, intentionally left out - tracked as a follow-up.

Note: invalid/malformed credentials now get a 401 instead of silently
falling back to anonymous - a deliberate, more-correct behavior change.

Testing

Verified on a live docker environment with Kerberos enabled, across all 5
endpoints x slash/no-slash x anonymous/valid-creds/invalid-creds x
ranger.admin.allow.unauthenticated.download.access=true/false:

• Slash and no-slash now always return the same result (the original bug).
• Flag false: anonymous -> 400, valid creds -> 200.
• Flag true: anonymous -> 200 (this was still 401 before the
  RangerKRBAuthenticationFilter fix).
• Invalid credentials -> 401 on all 5 endpoints, both flag states.
• Live SPNEGO ticket (kinit + curl --negotiate) against flag=false
  returned 200 with hadoop.auth cookie showing the real authenticated
  principal - confirms real Kerberos credentials are still fully validated,
  not waved through by the bypass.