NativeDDL: analyzing added&removed unique keys

[shlomi-noach]

Description

First, we're unofficially adopting the term "NativeDDL" for OnlineDDL/VReplication based migrations.
In this PR we add an analysis: does the migration introduce any new unique key constraints? Does it remove any unique key constraints?

The analysis isn't necessarily for a specific key. It is about the overall state of the table before/after migration. Is there a set of columns that was previous unconstrained and now forms a unqieu constraints? Regardless of how we got there, whether by ADD KEY or REMOVE KEY.

The information is persisted in schema_migrations table in these columns:

• added_unique_keys
• removed_unique_keys

both int unsigned not null default 0, and indicate the number of added constraints and number of removed constraints, respectively.

Why

This is fundamental to automating revertible migrations. Not all migrations are revertible. If you add a new constraint, and start using it, then reverting back to old table means you are now able to add what you consider as duplicates. And if you revert-the-revert (roll forward), then that may fail altogether.

So in this PR we first collect the information. Later on we can have educated logic based on that information.

Nothing right now actually uses the information gathered in this PR (other than in endtoend tests).

Change is tested in unit&endtoend tests.

Related Issue(s)

#6926

Checklist

• Tests were added or are not required
• Documentation was added or is not required

[deepthi]

LGTM