WL#4326: Online Backup: Disable events and triggers during restore.

RATIONALE

Fix so that restore does not fail if there are events, triggers
enabled on the restore server.
To fix BUG#36530.

SUMMARY

When restoring events and triggers, these objects should not be active
before the restore process completes. Note that restore operation is not
on-line and all tables being restored are locked. Also, data might be
inconsistent during the restore and become consistent only when the restore is
completed. Thus events and triggers which are created together with other
meta-data should not fire during the restore process.

DELIVERABLE:

Changes to the backup kernel which ensure that triggers and events do not fire
during the restore process but only when it is complete, i.e., all other objects
and all table data are restored.

PROPOSED SOLUTION: Change backup kernel so that events and triggers are created 
*after* all table data has been restored. Thus the events and triggers to be 
restored will not exist in the server when table data is restored.

Note: According to the analysis done for WL#4211 it is correct to recreate 
triggers and events at the end as no other object can depend on them. To be on the 
safe side, one should first create triggers and then events.

Serialization data for events and triggers is read before the table data. 
However, we can materialize a server object from its serialization string 
without actually creating it in the server. Object can be created later using 
execute() method. Thus events and triggers should be only materialized during 
metadata reading phase and executed after table data restore is completed.

It is enough to make these changes in the backup kernel code:

1. In function bcat_create_item(): do not execute a materialized object if it is 
a trigger or event.

2. In Backup_restore_ctx::do_restore() method: at the end, after a call to 
restore_table_data(), iterate over all triggers and then all events and execute
them.