WL#11063: Update server version information in InnoDB tablespaces

Update server version information in InnoDB tablespaces

In 8.0 we write the "server version number" to the tablespace header in all
relevant InnoDB tablespaces (i.e. user tablespaces and the data dictionary
tablespace). Hence, we have a way to associate user-data with a given server
version. Here we only register the '''birth-mark''', the server version number
which either did major upgrade, created, or imported the tablespace. It will
work like this:

* Upgrade from 5.7 to 8.0 will establish the version number in all tablespaces,
e.g. if user upgraded from 5.7 to "8.0.5" then "8.0.5" will be stored in all
tablespaces.
* The number will ''not'' be updated by MRUs. So even when a user upgrade to
"8.0.6" , version "8.0.5" will remain in all tablespaces. The same will be true
for downgrades.
* Any new tablespace ''created'' by any "8.0" server will store its version
number in the tablespaces, e.g. "8.0.13" will store "8.0.13".
* Any tablespace ''imported'' by any "8.0" server will store its version number
in the tablespaces, e.g. "8.0.20" importing a tablespace will store "8.0.20"
(after accepting it as a valid "8.0" tablespace).
* Upgrade from 8.0 to 9.0 will establish the version number in all tablespaces,
e.g. if user upgraded from "8.0.5" to "9.0.10" then "9.0.10" will be stored in
all tablespaces.

Notes: 
* Later we might update the version numbers also during all upgrade and downgrade
but for now we limit it to major upgrade
* Server version number in tablespaces can be generalized to all disk artifacts,
like configuration files.

- In-place upgrade from mysql-5.7 should add the server version number in every 
  tablespace on the page 0 of the tablespace, at byte 8
- In-place upgrade from mysql-5.7 should add the space version number in every 
  tablespace on the page 0 of the tablespace, at byte 12
- Importing any tablespace should add the current server version number in the   
  tablespace on the page 0 of the tablespace, at byte 8
- Importing any tablespace should add the current space version number in the   
  tablespace on the page 0 of the tablespace, at byte 12

While importing tablespace, mysql server version number and space version number
will be written to the tablespace in page zero. It will be done before creating
 SDI Index page in the tablespace.

WL#9461 mentions the upgrade flowchart when upgrading from mysql-5.7 to
mysql-8.0. Version number will be added to tablespaces in step 17 along with
creating SDI index in tablespaces (reference below).

A new handlerton API will be added which can used by Storage engines to update
version information in the tablespaces in case of upgrade.

API signauture:

typedef bool (*upgrade_space_version_t)(dd::Tablespace *tablespace);




For reference, the following flowchart is copied from WL#9461 worklog page.

Upgrade Flowchart:
==================
Flowchart of Upgrade from mysql-5.7 to a version with global data dictionary
after InnoDB changes will be as follows :

1.  Slow shutdown 5.7 server.
2.  Start 8.0 server on same data directory.
3.  Check if we are upgrading or restarting.
4.  Create a temporary file to record stages of upgrade to handle server crash 
    in case server is upgrading.
5.  Check that InnoDB undo log is empty, else empty undo log. (in scope of 
    WL#9357).
6.  Create Dictionary tables in old data directory.
7.  Update the temporary file maintaining stages of upgrade to mark that data 
    dictionary tables are created. This is important as InnoDB does not create 
    entry in undo logs for dictionary table creation.
8.  Initialize all stages of dictionary.
9.  Upgrade schema, i.e., create dictionary entry for schema.
10  Upgrade tablespaces, i.e., create dictionary entry for tablespace.
11. In upgrading table, get se_private_data and foreign key data from storage 
    engine.
12. Upgrade views without fixing view dependency.
13. Upgrade Events.
14. Upgrade SP/SF.
15. Fix view dependency.
16. Create a marking that we have migrated all meta data from other storage 
    engines to dictionary. It is done in temporary file created to record 
    progress of upgrade.

    InnoDB will change .ibd files after this stage. Even if server is killed 
    after this step, upgrade will only roll forward and complete only steps 
    after this ( step 18 onwards). Upgrade can't roll back its changes after 
    this step is complete.

17. Iterate over all tablespaces and tables to create SDI information.
18. Cleanup after upgrade, delete all .frm, .TRG, .TRN, .opt and other files 
    used by mysql-5.7. Drop mysql.proc and mysql.event system tables used by 
    mysql-5.7. Delete the temporary file created to record progress of upgrade.