[close #371] Upgrade client-go/tidb to release 7.5

[pingyu]

What problem does this PR solve?

Issue Number: close #371

Problem Description: Fail to bump grpc 1.59

grpc 1.59 move the path of package google.golang.org/grpc/test/grpc_testing, which is required by github.com/pingcap/tidb/store/mockstore -> go.etcd.io/etcd/pkg/v3/grpc_testing.

So upgrade dependency of TiDB to solve this issue.

What is changed and how does it work?

• Upgrade dependency client-go/tidb to release-7.5, which is the latest LTS version.
  • Client-go: https://github.com/tikv/client-go/commits/tidb-7.5
  • TiDB: https://github.com/pingcap/tidb/commits/release-7.5

Code changes

• No code

Check List for Tests

This PR has been tested by at least one of the following methods:

• Unit test
• Integration test

Side effects

• No side effects

Related changes

• No related changes

To reviewers

Please follow these principles to check this pull requests:

• Concentration. One pull request should only do one thing. No matter how small it is, the change does exactly one thing and gets it right. Don't mix other changes into it.
• Tests. A pull request should be test covered, whether the tests are unit tests, integration tests, or end-to-end tests. Tests should be sufficient, correct and don't slow down the CI pipeline largely.
• Functionality. The pull request should implement what the author intends to do and fit well in the existing code base, resolve a real problem for TiDB/TiKV users. To get the author's intention and the pull request design, you could follow the discussions in the corresponding GitHub issue or internal.tidb.io topic.
• Style. Code in the pull request should follow common programming style. (For Go, we have style checkers in CI). However, sometimes the existing code is inconsistent with the style guide, you should maintain consistency with the existing code or file a new issue to fix the existing code style first.
• Documentation. If a pull request changes how users build, test, interact with, or release code, you must check whether it also updates the related documentation such as READMEs and any generated reference docs. Similarly, if a pull request deletes or deprecates code, you must check whether or not the corresponding documentation should also be deleted.
• Performance. If you find the pull request may affect performance, you could ask the author to provide a benchmark result.

(The above text mainly refers to TiDB Development Guide. It's also highly recommended to read about Writing code review comments)

[codecov]

Codecov Report

Merging #372 (b43702d) into main (e63537b) will increase coverage by 0.2020%.
The diff coverage is 100.0000%.

Additional details and impacted files

@@               Coverage Diff                @@
##               main       #372        +/-   ##
================================================
+ Coverage   61.6247%   61.8268%   +0.2020%     
================================================
  Files           240        241         +1     
  Lines         20052      20221       +169     
================================================
+ Hits          12357      12502       +145     
- Misses         6578       6579         +1     
- Partials       1117       1140        +23     

Flag	Coverage Δ		*Carryforward flag
br	60.5013% <ø> (ø)		Carriedforward from ab52925
cdc	62.4438% <100.0000%> (+0.2896%)	⬆️

*This pull request uses carry forward flags. Click here to find out more.

Files	Coverage Δ
cdc/cdc/sorter/unified/backend_pool.go	66.9811% <ø> (ø)
cdc/pkg/db/pebble.go	89.5161% <100.0000%> (ø)
cdc/pkg/etcd/etcd.go	51.9519% <100.0000%> (ø)
cdc/pkg/regionspan/span.go	56.0975% <ø> (ø)
cdc/pkg/util/tz.go	44.0000% <ø> (ø)

... and 32 files with indirect coverage changes

[zeminzhou]

LGTM