schemadiff: analyze and apply ADD PARTITION and DROP PARTITION statements

[shlomi-noach]

Description

In this PR, schemadiff is able to:

• Generate multiple diffs for a table diff. A new function, EntityDiff.SubsequentDiff() returns the next-in-line diff for a given diff (or nil) if these is none. Essentially, a diff is the head of a linked list. The helper function AllSubsequent() turns such a linked list into a slice.

  • the single use case for this new behavior right now (and for as long as I can predict) is partitioing, illustrated below.

• Utilize RangeRotationStatements in DiffHints

• Diff two range-partition tables and analyze a sequence of DROP PARTITION and ADD PARTITION diffs. If partitions have rotated between the two tables (dropped "old" partitions from the 1st, added "new" partitions to the 2nd) then Diff() returns a sequence of EntityDiffs, approachable via SubsequentDiff() (see above), that can only be applied in-order to get into the new table format. These begin with the oldest DROP PARTITION and end up with the newest ADD PARTITION.

• Apply() now not only applies the given EntityDiff but also implicitly all subsequent diffs.

  • As a reminder, when RangeRotationStrategy is RangeRotationFullSpec (the default) we just get a single AlterTableEntityDiff which has the full partitioning spec
  • Also as reminder, when RangeRotationStrategy is RangeRotationIgnore , and if this is a range partition rotation, the partitioning change is silently ignored. If this is not a rotation, a full spec is generated.

Related Issue(s)

• schemadiff: tracking issue #10203
• schemadiff: partitions validations #10229

Checklist

• "Backport me!" label has been added if this change should be backported
• Tests were added or are not required
• Documentation was added or is not required

[github-actions]

Review Checklist

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

General

• Ensure that the Pull Request has the correct release notes label. release notes none should only be used for PRs that are so trivial that they need not be included.
• If a new flag is being introduced, review whether it is really needed. The flag names should be clear and intuitive (as far as possible), and the flag's help should be descriptive.

Bug fixes

• There should be at least one unit or end-to-end test.
• The Pull Request description should either include a link to an issue that describes the bug OR an actual description of the bug and how to reproduce, along with a description of the fix.

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.

[shlomi-noach]

I've converted this PR to Draft. I want to explore an idea by @dbussink where a table diff might generate a sequence of diffs, not just a single one; such that we might diff two tables with multiple partition rotation changes, and generate a one-change-at-a-time sequence of alters.

[shlomi-noach]

Ready to review: this PR now supports a diff that is a sequence of steps, in particular a sequence of DROP PARTITION and ADD PARTITION that compose a complex range partition rotation operation.

[dbussink]

One small question here, but nothing blocking.