WL#7898: Use DD API to work with events

WL#6388 provides new DD API to work with events.


The scope of this Work Log (WL) task is:
* Use new Data Dictionary (DD) dd::Event object and the related APIs for create,
  alter, drop and load events meta-information.

Related Work Logs:
WL#6388:- Define and Implement API for Events.
WL#6391:- Hide DD system tables from users.

F-1: Boostrap procedure must not create mysql.event table.
     mysql.event table is created during initialize phase using the 
     system script mysql_system_tables.sql. Modify this script to avoid 
     creation of mysql.event table. 

F-2: Boostrap initialization phase of new DD code shall create the mysql.events 
     table.
     
     With F-1 and F-2, event DD tables shall be hidden from users. (Please 
     refer "WL#6391 - Hide DD System tables from user.")

F-3: Create Event operation shall store metadata of Events in mysql.events meta
     table using New DD APIs and it's corresponding Dictionary object.

F-4: Drop operation shall remove metadata relating to the Event for which drop
     operation is performed by using New DD APIs.

F-5: Modification to Event related meta-information shall be performed using New
     Data Dictionary APIs.

F-6: New DD API shall be used to fetch meta-information relating to Event.

F-7: New DD API to fetch list of all event names and as well as events that 
     fall under a particular schema shall be used to display information of
     all events/under a particular schema as well as drop all events that
     belong to a schema.

F-8: Information Schema Events table shall fetch data by making using of the
     new DD API to show information that relate to Events.


NF-1: Using new DD table and DD APIs should not have any effect on functional
      features of Events.

WL uses the new Data Dictionary (APIs) and Data Dictionary table Events provided 
by WL#6388 to create, drop , alter and load events metadata.

Currently the events metadata is stored in mysql.event table (MyISAM). The 
current event subsystem directly write to mysql.event table by making use of the 
handler APIs.

The worklog does the following things:

A. Provide auxiliary APIs in dd namespace to create, drop, alter and load events
   that make use of the underlying dictionary client interface required to 
   persist the meta information 

B. Make use of the auxiliary APIs in the existing Events subsystem server code
   to implement the Events operational functionality and the related 
   modifications required to use the auxiliary APIs. This worklog will not make
   any major changes to the existing design of the Events subsystem in the 
   server code.

A: Auxiliary Support APIs in the dd namespace
----------------------------------------------

As part of this WL, the following support APIs are introduced to operate on DD 
tables using DD APIs. These methods are called by the Event subsystem of the 
server.

1. Get Event by Schema name and Event name
    - Acquire Schema object corresponding to schema name using dictionary 
      client interface method acquire
    - Acquire Event object by Schema name and event name via the dictionary 
      client interface method acquire. If this is successful, the method a 
      pointer to the Event dictionary object else null
    - The dictionary client interface may result in deadlock or timeouts,
      the method will return true and the Event object shall be null.
    - If the Event object is acquired is successfully , the method return true
      and the pointer to Event object is available in parameter of the event
      object that is passed by reference. 

2. Check Event Exists 
    - The Check Event Exists method uses the Get Event method to acquire the
      pointer to the event object and thus check for it's existence.
    - The method returns false on operational errors such as deadlocks or 
      timeouts that is possible. 
    - If there is no operational error, the method returns true and if the
      event exists then it populates the passed in bool reference argument 
      with true or else false
    
2. Create Event 
    - Acquire schema object under which event to be created.
    - Invoke create event API provided by WL#6388.
    - Set the Event attributes using the Parsed Event data available.
    - Store the Event object by invoking the dictionary client interface.
    - Commit the transaction if the store succeeds or otherwise rollback.

3. Drop Event
    - Call drop event using the dictionary client interface to
      drop objects.
    - If the drop dictionary object call succeeds, commit the transaction else 
      rollback.
    - Please note the caller of the drop event method shall check for existence
      of event.

4. Alter Event
    - Call Get Event by Schema name and Event name and obtain the handle to the
      Event object.
    - Modify the event attributes from the Parsed Event Data.
    - Call dictionary client interface update method.
    - If the above call succeeds, commit the transaction else rollback.

5. Drop all Events Under a Schema
    - Loop through list of all event objects under the schema using the iterator 
      interface.
    - For each event obj, call the Drop Event method to drop the object
      corresponding to schema name and event name.
    - This used is while during drop databases.    


6. Get Event Schema Name
     - This method tries to acquire schema name given a schema id.
     - Call uncached acquire to obtain the schema object corresponding to
       schema id.
     - Fill in the schema name from the schema object.
     - This method is used when during event initialization or retrieving 
       event information for filling information schema. We usually iterate
       list of all events. During this phase, we retrieve schema id from event
       object and get corresponding schema name either for information purpose
       or destructive update like drop.

7. Update Event Time Fields
   - Get the handle to the event object using the event name and schema name.
   - Set the last executed and status attribute of the object.
   - Update the event dictionary object by calling dictionary object client 
     interface.
   - If the above call succeeds, 
   

Type conversion to convert enum types between legacy enums and enums relate to 
Event object types in dd namespace.


1. Get Old Status: Convert DD event status to Legacy Event Status.

2. Get Enum Event Status: Convert Legacy Event status to DD Event status.

3. Get Old On Completion: Convert DD Event On Completion type to Legacy On 
   Completion type.

4. Get On Completion: Convert Legacy on completion to DD Event on completion. 

5. Get Old Interval Type: Convert Interval type of DD Event (known as Interval 
   Field) to Legacy Interval type.
   to 

6. Get Enum Interval Field: Convert Legacy Interval field to DD Event Interval
   Type (aka known in DD as Interval Field)



B: Modifications in the Event subsystem of server code:

There would be no major changes in the except instead of direct handler calls 
that fetch data related to event in the event subsystem shall be handled by dd 
auxiliary APIs explained in A above. 

The Event_db_repository class abstracts the details of communication underlying 
storage layer to fetch meta information in the current Event Design. They 
implement nearly the same method as explained in A above and use the handler 
calls correctly. This class along with it's methods shall be retained and will 
serve as the adapter to fetch the related meta information.
This class method is modified to make use of the DD auxiliary API to fetch 
information.
The find_named_event of this class is removed and we use the dd::event_exists 
directly in various class method APIs as and when required.

There is a runtime hierarchy of classes that derive from Event_basic and this 
include the Event_timed, Event_job_data and Event_queue_element. All of this  
has various event related attributes some of them normalized plus additional 
attributes with clear defined functionalities required for runtime event 
operational semantics. Currently all of them have a implement the virtual 
load_from_row that fill in the necessary attribute by fetching information 
directly from the table via the load_named_event method of the 
Event_db_repository. This load_from_row method is replaced by fill_event_info 
that shall  take an event object and fill out the necessary attributes required 
for operational semantics of these classes.  This design choice keeps the 
existing events class design clean and maintains the original design and is 
optimal in terms of management and ownership of  the Event information.


C: User-noticeable Changes:

1. User need not do any implicit LOCK TABLE to operate/manipulate/use Event 
   related things. Direct access to the Events meta table is disallowed.
2. MDL locks are acquired for doing event related functionality including 
   read operation. This methods provides general correctness and serialized
   view of concurrent operations among concurrent users using the events
   functionality.
3. This WL shall remove mysql.event table and provides new meta table 
   mysql.events and the structure of column name and their types is a 
   little bit different from mysql.event.
   This will have some impact on user land tools like mysqlupgrade and
   privileges which shall be taken care by other relevant worklogs: