RANGER-5624: Fix inconsistent updatedBy masking in get groups/groupName

[krishnamuttevi]

Currently, there is an inconsistency in the masking behavior of the updatedBy field in VXGroup responses across group retrieval APIs. When a group is fetched by its ID (GET /xusers/groups/{id}), the field is correctly masked to prevent metadata leakage. However, retrieving the exact same group by its name ( GET /xusers/groups/groupName/ group_name} ) bypasses this masking and exposes the actual user value (e.g., "Admin"). This inconsistency leads to an unreliable API contract and the unintended exposure of sensitive user-related metadata.

This was solved by:

1. Resolve the group ID using the requested group name directly within the xuserrest layer.

2. Route the subsequent retrieval call through the existing xUserMgr.getXGroup(id) method.

3. Update the following unit tests accordingly

Align the underlying logic so both endpoints share the exact same retrieval pipeline, ensuring the updatedBy field is consistently masked across all responses.

[pradeepagrawal8184]

what is the behavior if a non-admin(user role) user is accessing a group when he is part of the group and when he is not.

[krishnamuttevi]

here if it is a non admin role - (auditor, keyadmin)
passes both masked and exception

but if non admin role - (user) + non group member - it gives 403 forbidden
and non admin role - (user) + group member - it gives vxgroup with masked updated by field

[ramackri]

Reviewed against RANGER-5627 (#1000) and the existing XUserMgr.getXGroup(Long id) pipeline.

Verdict: Approve. This change is correct and complementary to #1000, not conflicting with it.

Why this is the right fix

After #1000, getXGroupByGroupName duplicated ROLE_USER membership logic inline in XUserREST but skipped the getMaskedVXGroup() path that getXGroup(id) already applies when the caller lacks MODULE_USER_GROUPS access. That is exactly the updatedBy leakage described in RANGER-5624.

Routing name-based lookup through xUserMgr.getXGroup(id) aligns both endpoints on the same pipeline:

1. ROLE_USER membership enforcement (isSingleRoleUserSession() + group-id check)
2. Config super-user bypass (unchanged — handled inside getXGroup)
3. Consistent updatedBy masking via getMaskedVXGroup()

Interaction with RANGER-5627

No breakage expected. The removed inline block in XUserREST is redundant once delegation goes to XUserMgr.getXGroup() — that method already contains the post-5627 access rules. Config super-users continue to bypass ROLE_USER restrictions via isSingleRoleUserSession() semantics in UserSessionBase.

Minor notes

• getGroupByGroupName() throws DATA_NOT_FOUND for unknown names, so vXGroup.getId() is safe in normal flow (no null return).
• Non-member ROLE_USER behavior becomes consistent with GET /groups/{id} (403 via getXGroup) instead of returning null — this is an improvement, not a regression.
• Unit test update correctly mocks xUserMgr.getXGroup(id); CI is green.