WL#6752: Online rename index - InnoDB part

Status: Complete   —   Priority: Medium

This is to track the InnoDB part of online index rename. The changes to parser,
MDL, SE API are done under WL#6555.
The rename consists of 3 phases:

1. Renaming in InnoDB data dictionary (SYS_INDEXES)
2. Renaming in InnoDB data dictionary cache (the dict_table_t/dict_index_t objects)
3. Renaming in InnoDB persistent stats storage

If the ALTER TABLE is rebuilding the table, then 1. and 2. can be skipped
because the new table is created with the correct structure.

All the steps are done in the commit phase of the ALTER TABLE.

An example rename of an index:

ALTER TABLE t RENAME INDEX i1 TO i2;
If the ALTER TABLE has gone via the 'rebuild' path (new clustered index has been
built), then 1. and 2. are noops since the new table is created with the correct
new names of the indexes. Then we only handle the rename in persistent stats
storage via the newly added function alter_stats_rebuild(), called from
ha_innobase::commit_inplace_alter_table().

If the ALTER TABLE has gone via the 'no-rebuild' path, then we perform the steps
as follows:
1. Call the newly added function rename_indexes_in_data_dictionary() from
commit_try_norebuild(), called from ha_innobase::commit_inplace_alter_table()
2. Call the newly added function rename_indexes_in_cache() from
commit_cache_norebuild(), called from ha_innobase::commit_inplace_alter_table().
3. Call the newly added function alter_stats_norebuild() from
ha_innobase::commit_inplace_alter_table().

The operation could fail due to:

1. incorrect name of the new index given
2. any of the errors que_eval_sql() could emit