RANGER-5678: Concurrent policy-engine rebuild on shared serviceDef causes CME/NPE for delegated-admin User

[vyommani]

What changes were proposed in this pull request?

Under concurrent delegated-admin V2 API load, multiple threads rebuild the policy engine for the same service — or for services that share a tag serviceDef — at the same time. Each rebuild calls ServiceDefUtil.normalize() on the shared, cached RangerServiceDef, which mutates it in place, causing ConcurrentModificationException/NullPointerException under concurrent access.
The fix makes ServiceDefUtil.normalize() return a deep copy of the RangerServiceDef instead of mutating its input.

Initially, I assumed adding copy constructors and changing normalize() to copy-then-mutate would be enough on its own. However, ServiceDefUtil.normalize() was both mutating its input and returning it — which made its original intent ambiguous: was the return value meant to be authoritative, or was it just a convenience alongside the real effect (the in-place mutation)? Rather than guess, I took the conservative approach: treat the return value as authoritative, and update every call site to propagate the returned (now-copied) RangerServiceDef back to wherever the caller had originally expected the mutation to be visible. This keeps the change behavior-preserving — nothing that depended on seeing the normalized state after calling normalize() loses that guarantee — while fully resolving the CME/NPE.

How was this patch tested?

Existing unit tests updated and passing.
New test testNormalizeDoesNotMutateOrShareStateWithSource verifies identity and content isolation.
Local concurrency exercises (same serviceDef + cross-service shared tag serviceDef) no longer reproduce the CME/NPE

[vyommani]

@mneethiraj , @pradeepagrawal8184 , can you please review this PR when you get time.