external_storage: implement locking

[YuJuncen]

What problem does this PR solve?

Issue Number: close #56523

Problem Summary:

See the issue. We need a safer method to lock the external storage.

What changed and how does it work?

This PR implemented the "put and verify" txn, also a document was provided.

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.

Release note

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

None

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from yujuncen, ensuring that each of them provides their approval before proceeding. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS
• br/OWNERS
• br/pkg/storage/OWNERS

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

[tiprow]

Hi @YuJuncen. 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 74.10072% with 36 lines in your changes missing coverage. Please review.

Project coverage is 57.6708%. Comparing base (0a2d5be) to head (dda8f11).
Report is 492 commits behind head on master.

Additional details and impacted files

@@                Coverage Diff                @@
##             master     #56597         +/-   ##
=================================================
- Coverage   74.8131%   57.6708%   -17.1424%     
=================================================
  Files          1570       1832        +262     
  Lines        364718     686956     +322238     
=================================================
+ Hits         272857     396173     +123316     
- Misses        72124     264845     +192721     
- Partials      19737      25938       +6201     

Flag	Coverage Δ
integration	39.0002% <33.8129%> (?)
unit	72.4678% <74.1007%> (-1.2812%)	⬇️

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

Components	Coverage Δ
dumpling	52.9478% <ø> (-2.2416%)	⬇️
parser	∅ <ø> (∅)
br	55.8407% <74.1007%> (+8.1500%)	⬆️

[ti-chi-bot]

@YuJuncen: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
idc-jenkins-ci-tidb/check_dev_2	dda8f11	link	true	/test check-dev2
pull-br-integration-test	dda8f11	link	true	/test pull-br-integration-test

Full PR test history. Your PR dashboard.

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/test-infra repository. I understand the commands that are listed here.

[lance6716]

When contention is high no one can commit? It doesn't scale.

[YuJuncen]

Perhaps a randomized back off algorithm can help. Anyway this is like some sort of optimistic lock, hence not pretty effective in the scenario that tons of clients racing for one lock...

[lance6716]

OK if there will not be too many clients in the use case