Determine the dependency update strategy between BR and TiDB

[kennytm]

Currently BR depends on TiDB to execute DDLs in-place during restore (plus other stuff), and TiDB depends on BR to run the BACKUP / RESTORE statements.

The cyclic dependency makes upgrading them very tedious, especially when the changes involves public APIs. For instance,

• in config: remove allow-auto-random config option tidb#16596 we cannot directly lift an experimental TiDB config out because BR was still relying on it until restore: remove auto_random option #343.
• in task: expose table filter for backup full and restore full #313 we need to keep two useless configurations because TiDB was still relying on them.

This issue records the strategy how should we perform such upgrades.

[kennytm]

1. Breaking change caused by deprecated APIs

Perform this if TiDB or BR would like to deprecate or remove a public API.

Do not perform this if no breaking change is introduced. Wait for regular updates instead.

Below we are going to call the module deprecating API as "Project A" and the other module as "Project B"

I. Deprecation

Example: #313. In BR we deprecated the use of black-white-list Filter. Unfortunately, due to cyclic dependency, the embedded TiDB should contains code which relies on the old Filter.

1. Implement the new API but keep the existing API in Project A, but mark them as // Deprecated:. Submit the PR for Project A.
2. Upgrade dependency in B, and transition to use the new APIs. Submit the PR for Project B.
3. Upgrade dependency in A, and remove the deprecated API. Submit the PR for Project A.

II. Removal

Example: pingcap/tidb#16596. In TiDB we removed the experimental config AllowAutoRandom, as it has become the default. This is a special case of I since step 1 becomes no-op.

1. (Ensure the API to be removed is really no-op in Project A.)
2. Remove use of deprecated API in B. Submit the PR for Project B.
3. Upgrade dependency in A, and remove the deprecated API. Submit the PR for Project A.

III. Cherry-picking

The 3 steps should be done independently for every release channel.

[kennytm]

2. Regular updates

We need to regularly update the TiDB and BR dependencies to keep the bug fixes up-to-date.

1. We should upgrade the BR dependency in TiDB X days before release freeze.
2. We should upgrade the TiDB dependency in BR Y days before release freeze.

(TODO: determine X and Y)

[IANTHEREAL]

There are two other options.

Option 1: Put the BR code under pkg/backup or pkg/restore of tidb
Option 2: Make the plugin support br/cdc integration

• tidb plugin specifically supports BR/CDC.
• tidb supports for generic third-party plugins
  • extend Audit plugin to have Pre-parse Query Rewrite capability
  • allow (all) plugins to provide a web interface
  • allow users to provide initial values to custom system variables