schemadiff: normalize PRIMARY KEY definition

[shlomi-noach]

Description

In this PR we normalize and validate PRIMARY KEY definitions:

1. Normalize and validate CREATE TABLE

This statement:

create table t (id int primary key)

is normalized into:

create table t (id int, primary key(id))

Table definition is validated to have no more than one PRIMARY KEY.

2. Validate ADD COLUMN

In this statement:

alter table t add column i int primary key

We validate that the table does not already have a PRIMARY KEY. Once applied, the table definition is normalized as per the above.

3. Validate MODIFY COLUMN

In this statement:

alter table t modify column i int primary key

We validate that the table either:

• does not already have a PRIMARY KEY, or
• already has a PRIMARY KEY (i), ie no change to the PRIMARY KEY itself.

Once applied, the table definition is normalized as per the above.

4. Table diffs change

The diff of these two tables:

create table t (id int primary key);
create table t (id bigint primary key);

is:

alter table t modify column id bigint

Note that there is nothing to say that id is a PRIMARY KEY even though the original definitions included that information as part of column definition options. The reason is that internally the tables are normalized as per (1) above.

---

Several tests are added to validate all the above. Otherwise there's been a massive impact to unit tests because we used the id int primary key generously throughout the tests, and had to rewrite dozens of those.

Related Issue(s)

tracking: #10203

This work is needed for better foreign key support in schemadiff: it needs to validate that a parent table referenced by a foreign key, has the appropriate indexes over the referenced columns. It's then important to have the PRIMARY KEY normalized as this PR does. See #11975 and #11944

Otherwise, this is just the right way of normalizing a table. SHOW CREATE TABLE in MySQL always extracts PRIMARY KEY information outside the column definition.

Checklist

• "Backport to:" labels have been added if this change should be back-ported
• Tests were added or are not required
• Documentation was added or is not required

Deployment Notes

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• If this is a change that users need to know about, please apply the release notes (needs details) label so that merging is blocked unless the summary release notes document is included.
• If a test is added or modified, there should be a documentation on top of the test to explain what the expected behavior is what the test does.

If a new flag is being introduced:

• Is it really necessary to add this flag?
• Flag names should be clear and intuitive (as far as possible)
• Help text should be descriptive.
• Flag names should use dashes (-) as word separators rather than underscores (_).

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow should be required, the maintainer team should be notified.

Bug fixes

• There should be at least one unit or end-to-end test.
• The Pull Request description should include a link to an issue that describes the bug.

Non-trivial changes

• There should be some code comments as to why things are implemented the way they are.

New/Existing features

• Should be documented, either by modifying the existing documentation or creating new documentation.
• New features should have a link to a feature request issue or an RFC that documents the use cases, corner cases and test cases.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• vtctl command output order should be stable and awk-able.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from VTop, if used there.

[shlomi-noach]

The change in go/vt/sqlparser is to make the above constants public, so that we can introspect a ColumnDefinition and see whether it has a specific key option.

[deepthi]

LGTM