WL#12820: Extend GRANT syntax to cover partial revokes information

WL#12098 introduced concept of partial revokes associated with global privileges
grants. In an HA environment, grants and revoke require knowledge of grantor's
context to be able to replicate the effect of the grant uniformly across
different nodes. This is done by adding grantor's information in binary log's
query log event header. Secondary nodes use this information to set required
context and replay grant/revoke.

However, for tools like mysqlbinlog, there is no way to set grantor's context
because it uses a regular libmysqlclient connection. This impacts point in time
recovery using mysqlbinlog because grants can not be replayed reliably.

This worklog aims at introducing extensions to GRANT/REVOKE syntax such that
partial revoke information is passed as a part of SQL itself. Feature will make
sure that rewritten GRANT/REVOKE are not dependent on grantor's information and
can be replayed uniformly on any node.

Definition
==========
User:         User executing GRANT statement.

Grantor:      Authorization ID that is a part of new syntax extension.

Active_roles: Authorization IDs treated as active roles for Grantor - Also 
              explicitly specified as a part of new syntax extension.

Functional Requirements
=======================

FR1: Server should support an extension to GRANT syntax to specify information 
     about grantor and active roles information.  New extension:

     [AS user
       [WITH ROLE
         DEFAULT
         | NONE
         | ALL
         | ALL EXCEPT role [, role ] ...]
         | role [, role ] ...]
     ]
 
     Complete GRANT syntax should look like following:	 
	 GRANT
           priv_type [(column_list)]
             [, priv_type [(column_list)]] ...
           ON [object_type] priv_level
           TO user_or_role [, user_or_role] ...
           [WITH GRANT OPTION]       
           [AS user
             [WITH ROLE
               DEFAULT
               | NONE
               | ALL
               | ALL EXCEPT role [, role ] ...]
               | role [, role ] ...]
           ]

     Purpose of the new syntax extension is to make sure that restrictions
     associated with Grantor (and Active_roles) are applied to grantee
     even if statement is executed by User - who may have superior set of
     privileges.

FR2: In order to specify new extension, following privilege restrictions apply:
     1. User must have ability to grant all privileges mentioned
        in GRANT statement
     2. If --partial_revoke is set to ON and if User has restrictions
        associated with privileges being granted through GRANT statement, 
        Grantor along with all Active_roles set, must also have same
        or more restrictions.

FR3: The new extension should work only for global privilege grants i.e. if
priv_level is *.*.
FR3.1: Exception to FR3 is GRANT PROXY. New extension will not be supported
       for proxy grants.

FR4: Effect on query logging:
     1. If --partial_revokes is set to ON, while rewriting GRANT to
        binary log, information about Grantor and Active_roles
        should be added to binary log.
     2. GRANT must not be rewritten for any other logs
        e.g. general log, audit log etc.

FR5: Impact on replication:
     1. Please see point 1 of FR4 for impact on binary log.
     2. Changes introduced to binary log query event header by
        WL#12098 must be reverted because they are no longer needed.
	
FR6: Incompatibility warnings introduced by while setting --partial_revokes
     should be removed as they are no longer required. These were introduced
     by WL#12098.

HLS1: GRANT will support new clause as mentioned in FR1. LEX will be
      updated to contain information about new clause in GRANT statement.
      Parser will be changed to support new clause for:
	  GRANT ... TO ...
	  GRANT ALL ON *.* TO ...

      A special case of GRANT ... AS ... is when user executing the 
      GRANT statement is same as user in AS clause - either by specifying
      user name explicitly or using CURRENT_USER(). A usecase for such
      usage is - a user who has activated many roles wants to make sure
      that only a subset of roles play part while granting privileges
      to grantee. This may be required in order to pass a stricter set
      of permission through e.g. restriction list.

HLS2: Rationale for FR2.
         The main use-case for the syntax extension is to make sure that
         information related to restrictions is available in binary log
         in SQL format so that mysqlbinlog can extract and execute it.

         The fundamental assumption here is: PITR through mysqlbinlog
         would typically use a user account that has privileges
         higher than regular users to make sure that ALL statements in
         binary logs are replayed without any problem.

         In case of PITR with --partial-revokes=ON, GRANT can cause a user
         to have more privileges than the actual grant executed by regular
         user with restriction list. This is because restrictions are
         are passed from grantor to grantee.
 
         If we do not check for privileges mentioned in point 1 and 2
	 of FR2, user may be able perform privilege escalation through new 
         statement because while intended use is for mysqlbinlog, it still
         is a valid SQL that can be explicitly executed.

         Hence, User executing GRANT must have superior privilege set then 
         user/role combination specified in AS ... part. Note that, only 
         privileges being granted through the statement are of interest at
         this point. We do not care of about difference wrt other privileges
         because they do not play any role in given GRANT statement.

HLS3: Rationale for FR5
      WL#12098 introduced new flag - ACTIVE_ROLES for query event header of 
      binary log. As per FR4, new extension will be used to capture
      invoker's context while rewriting query for binary log. Hence, there
      is no need to pass same information again through ACTIVE_ROLES and
      subsequently use it on slave side. Since both: WL#12098 and WL#12820
      are meant for same MRU, we can safely revert these changes without
      any customer visible impact.

HLS4: If --partial_revokes is set to ON, when GRANT is rewritten to binary log,
      it will always contain complete list of roles. We will not use keywords
      like NONE/DEFAULT/ALL. If user has explicitly specified GRANT ... AS ...
      query using NONE/DEFAULT/ALL, it will be logged as it is.

HLS5: Impact on replication
     - In case of OLD->NEW setup, behavior should be compatible.
     - In case of NEW->OLD setup, behavior is incompatible if extension     
       proposed in FR1 is used.

HLS6: No impact on UPGRADE