Decouple SET SESSION AUTHORIZATION operation from SET USER privilege

Description:

The SET USER privilege (SET_USER_ACL, bit 30) currently controls three capabilities:

• SET SESSION AUTHORIZATION - switching the session identity to another user
• DEFINER= clause - specifying a different definer on views, stored routines, and triggers
• Missing definer error visibility - revealing details when a definer account does not exist

These are fundamentally different operations. Setting a definer on a view is a metadata operation on a stored object. Switching session identity grants the full privilege set of the target user for the remainder of the session. A user who needs to create views with a specific definer should not automatically gain the ability to impersonate any other user.

Example:

-- User with SET USER privilege can switch to any other user's identity:

GRANT SET USER ON *.* TO admin@'%';

-- admin can now do:

SET SESSION AUTHORIZATION superuser@localhost;

-- Session now has all privileges of superuser@localhost

GRANT ALL PRIVILEGES ON *.* TO admin@'%' WITH GRANT OPTION;

A user granted SET USER for the purpose of managing definer clauses on views and routines can escalate privileges by switching their session identity to a more privileged user.

Proposed Fix:

Introduce a new privilege SET AUTHORIZATION (SET_AUTHORIZATION_ACL, bit 40) dedicated to SET SESSION AUTHORIZATION. The SET USER privilege would no longer grant the ability to switch session identity. Users who need to execute SET SESSION AUTHORIZATION must be explicitly granted SET AUTHORIZATION.

• SET USER continues to control the DEFINER= clause and missing definer visibility - no change to existing behavior for those operations.
• SUPER inherits SET AUTHORIZATION via ALLOWED_BY_SUPER_BEFORE_120300 for backward compatibility, so existing superusers are unaffected.
• SET SESSION AUTHORIZATION to self (same user/host) continues to work without any privilege.

Since SET SESSION AUTHORIZATION was introduced in 12.0 and the privilege model has no established user base depending on SET USER granting session switching, this change has no backward compatibility concerns for the target user population if included in 12.3 GA release else the users should explicitly grant this privilege as well (after upgrade).