WL#7900: New DD: Support flexible creation and versioning of virtual P_S tables

Affects: Server-8.0   —   Status: Complete

The scope of this worklog is limited only by server performance schema tables.
Plugin specific performance schema tables is out of scope for this worklog and
covered by separate worklog.

Overview
========

Supporting the creation and versioning of server P_S tables in the new DD
has two related aspects:

1. Create the P_S tables on behalf of the server P_S implementation to make
   the virtual tables visible in I_S queries. The table definitions may be
   retrieved from the P_S implementation in terms of SQL DDL statements.
   This mechanism may replace the currently hard coded table definitions
   executed when the server is initialized.

2. Provide support for versioning of the P_S table definitions to allow the
   table definitions to change independently of the server- or dictionary
   versioning scheme. This requires the versioning number to be stored in 
   mysql.dd_properties in the same way as for the I_S views.

Use cases
=========

1. Currently, the P_S table definitions are retrieved from SQL scripts
   executed when the server is bootstrapped. Instead, the table definitions
   can be retrieved from a P_S function as SQL DDL statements, which can
   then be executed by the DD initialization code. A mechanism similar to
   what the server and the DDSE uses for allowing the server to create
   tables on behalf the DDSE, may be used. The benefit of this would be to
   make the P_S more self contained. This worklog doesn't cover support
   of plugin versioning that will be implemented by a separate worklog.

   Since the I_S virtual tables are implemented as views on top of the 
   dictionary tables, it would simplify the implementation to have also the P_S 
   table meta data stored persistently. Otherwise, the I_S implementation would 
   need to fetch the P_S table meta data from the P_S implementation on demand, 
   thus complicating the implementation somewhat by requiring special handling 
   for P_S virtual tables.

2. For the P_S virtual tables, there is no persistent data, so upgrading to new
   P_S table definitions will simply mean to drop the current definitions and
   replace them by the new ones. The procedure will involve consulting, on
   server restart, the mysql.dd_properties table as part of the server
   performance schema initialization. If performance schema version stored
   as a property in this table differs from a version of performance schema
   supported by server the new P_S tables will be created basing on the set of
   table definitions returned by server performance schema.