br: separate the restore client

[Leavrth]

What problem does this PR solve?

Issue Number: ref #52877

Problem Summary:
enhancement: make the restore code structure more readable.

What changed and how does it work?

Separate the snap restore client and log restore client. And remove the FineGrained configure in the internal code.

Mostly modifies are code movements, and there are some code optimization:

1. (* br/pkg/restore/snap_client.SnapClient).CreateDatabases is moved into (* br/pkg/restore/internal/prealloc_db.DB).CreateDatabases. Make the function be the same as (* DB).CreateTable with supportPolicy and policyMap.
2. Introduced brContextManager/ImportModeSwitcher to move some functions out from br/pkg/restore/snap_client.SnapClient.
3. Since TiKV support multi-ingest in v5.0, remove the multi-ingest-not-support method, and just return error if not support multi ingest.
4. Deprecated parameter --granularity.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No need to test

  • I checked and no code files have been changed.

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[tiprow]

Hi @Leavrth. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[codecov]

Codecov Report

Attention: Patch coverage is 51.96271% with 1958 lines in your changes are missing coverage. Please review.

Project coverage is 74.1922%. Comparing base (491740b) to head (0ee820b).

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #53197        +/-   ##
================================================
+ Coverage   72.5147%   74.1922%   +1.6775%     
================================================
  Files          1498       1545        +47     
  Lines        429925     442418     +12493     
================================================
+ Hits         311759     328240     +16481     
+ Misses        98883      93392      -5491     
- Partials      19283      20786      +1503     

Flag	Coverage Δ
integration	51.2241% <41.3967%> (?)
unit	71.3557% <22.0068%> (-0.0553%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
dumpling	53.9957% <ø> (ø)
parser	∅ <ø> (∅)
br	49.4293% <51.9627%> (+7.8283%)	⬆️

[YuJuncen]

The new directory structure looks good to me. Hopefully we haven't modify and logic.

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2024-05-17 03:33:31.16537973 +0000 UTC m=+1796964.922515298: ☑️ agreed by YuJuncen.
• 2024-05-17 03:37:15.37423872 +0000 UTC m=+1797189.131374294: ☑️ agreed by 3pointer.

[lance6716]

/approve

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 3pointer, lance6716, YuJuncen

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• br/OWNERS [3pointer,YuJuncen]
• pkg/lightning/OWNERS [lance6716]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Leavrth]

/ok-to-test