ApplySchema: -skip_preflight

[shlomi-noach]

Description

This PR introduces -skip_preflight flag to vtctl ApplySchema. Preflight checks test the sanity of the schema change. As example, if we add a column c to a table that already has column c, preflight checks will intercept the error and the query never gets sent to the backend tables.

However, preflight checks don't always make sense:

• With online DDL, I could submit migration#1: add column c, and migration#2 add key c_idx(c). If migration#1 still runs when I submit migration#2, preflight rejects migration#2. This is counter productive to the online DDL concept.
• On unmanaged setups, preflight may not have the privileges to run, thus becoming impossible to execute.

The new flag -skip_preflight, defaults false for backwards compatibility, completely disables the use of preflight checks. When enabled, the query moves directly to the relevant shards.

Related Issue(s)

• Generally relevant context is Online DDL: tracking issue #6926 but other issues apply.

Checklist

• Should this PR be backported?
• Tests were added or are not required
• Documentation was added or is not required
  f work. These should note any db migrations, etc. -->

Impacted Areas in Vitess

Components that this PR will affect:

• Query Serving
• VReplication
• Cluster Management
• Build/CI
• VTAdmin

[aquarapid]

The code itself looks fine; but we should probably have a way to do the same for the SQL version of an online DDL (i.e. set @@ddl_strategy='gh-ost';... etc.)? It doesn't seem to be quite as straightforward, unless we introduce a fake argument for the ddl_strategy value, which we strip before passing to gh-ost (or pt-osc)?

[shlomi-noach]

The code itself looks fine; but we should probably have a way to do the same for the SQL version of an online DDL

I'm not sure what you're asking. There is no preflight check in the SQL version of Online DDL.

[aquarapid]

I'm not sure what you're asking. There is no preflight check in the SQL version of Online DDL.

Got it; I was under the impression it followed the same flow as ApplySchema with -ddl_strategy.

[shlomi-noach]

I was under the impression it followed the same flow as ApplySchema

One more reason to remove preflight from ApplySchema. the code paths are really very different.

[derekperkins]

ApplySchema is in a pretty bad state as is. It should either be deprecated and removed since it gets in the way as is, or promoted to be the preferred way of making changes and functionality added to incentivize people to use it. I lean towards deprecating it.

[deepthi]

ApplySchema is in a pretty bad state as is. It should either be deprecated and removed since it gets in the way as is, or promoted to be the preferred way of making changes and functionality added to incentivize people to use it. I lean towards deprecating it.

I also vote for deprecation.