Enable multiple sequential EXECUTE AS statements on the same connection by checking IMPERSONATE privileges based on the original login user instead of the current impersonated user.

• Store original user context (identity, groups, roles) in AccessControlContext
• Initialize original context during authentication
• Use original context for IMPERSONATE checks in AuthorizationMgr.canExecuteAs()
• Add test case for EXECUTE AS chaining scenario
• Fix security issue: reset original context on re-authentication to prevent
  new user from inheriting IMPERSONATE privileges from previous login user

Maintains backward compatibility with fallback to current user behavior.

Why I'm doing:

Currently, when using EXECUTE AS user WITH NO REVERT, the system checks IMPERSONATE privileges based on the current impersonated user (currentUserIdentity), not the original login user (qualifiedUser). This creates a limitation where:

1. After executing EXECUTE AS user1 WITH NO REVERT, the connection context switches to user1
2. When attempting to execute EXECUTE AS user2 WITH NO REVERT on the same connection, the system checks if user1 has IMPERSONATE privilege on user2
3. If user1 doesn't have IMPERSONATE privilege on user2, the operation fails, even though the original login user (e.g., admin_user) might have IMPERSONATE privileges on both user1 and user2

This limitation prevents applications using connection pooling from chaining multiple EXECUTE AS statements on the same connection, forcing them to either:

• Grant IMPERSONATE privileges to intermediate users (not always feasible)
• Use separate connections for each user (defeats connection pooling)

What I'm doing:

This PR enables EXECUTE AS to check IMPERSONATE privileges based on the original login user instead of the current impersonated user, allowing multiple sequential EXECUTE AS statements on the same connection.

Implementation details:

1. Store original user context in AccessControlContext:

   • Added originalUserIdentity, originalGroups, and originalRoleIds fields to store the original login user context snapshot
   • These fields are initialized once during authentication and remain unchanged during the session

2. Initialize original context in AuthenticationHandler:

   • Call initOriginalUserContext() after setting groups and roles during authentication
   • This ensures the original user context is captured at login time

3. Modify privilege checking in AuthorizationMgr.canExecuteAs():

   • Use original user context (identity, groups, roles) for IMPERSONATE privilege checks when available
   • Fallback to current user behavior if original context is not available (for backward compatibility)

4. Add test case to verify the feature:

   • Test case testExecuteAsChainUsesOriginalLoginUserForImpersonateCheck() verifies that chaining EXECUTE AS statements works correctly based on original user privileges

Example usage:
-- Login as admin_user (has IMPERSONATE on user1 and user2)
EXECUTE AS user1 WITH NO REVERT; -- Checks: admin_user has IMPERSONATE on user1 ✓
-- ... execute queries with user1 permissions ...
EXECUTE AS user2 WITH NO REVERT; -- Checks: admin_user has IMPERSONATE on user2 ✓ (now works!)

Fixes #68149

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
  • This pr needs auto generate documentation
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 4.1
  • 4.0
  • 3.5
  • 3.4