ldap: add timeout mechanism and optimize lock for LDAP dial and requests

[YangKeao]

What problem does this PR solve?

Issue Number: close #51883

Problem Summary:

There are two problems:

1. A pending LDAP authentication process will block rebuildSysVarCache.
2. If the LDAP connection lost after the first handshake, the LDAP goroutine and function call will hang forever.

What changed and how does it work?

I have done two modification to fix this problem:

1. Refactor the original ldapAuthImpl to ldapAuthImplBuilder, which will copy the configurations (and take a reference to the connection pool, which include a closure with a copy of connection configurations). Therefore, during the scope of any lock, there didn't exist any IO operation, so that the rebuildSysVarCache will not be blocked by a network connection.
2. Add timeout to the LDAP requests.

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.

I used the yangkeao/ldap-sasl-example container to run the manual test, steps:

TODO

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 yangkeao, 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

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

[codecov]

Codecov Report

Attention: Patch coverage is 62.78027% with 83 lines in your changes missing coverage. Please review.

Project coverage is 75.0818%. Comparing base (7a20e43) to head (ffa01ca).
Report is 1658 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #51912        +/-   ##
================================================
+ Coverage   72.1416%   75.0818%   +2.9402%     
================================================
  Files          1467       1489        +22     
  Lines        426665     435562      +8897     
================================================
+ Hits         307803     327028     +19225     
+ Misses        99697      87623     -12074     
- Partials      19165      20911      +1746     

Flag	Coverage Δ
integration	51.6517% <41.2556%> (?)
unit	70.9592% <62.7802%> (-0.0691%)	⬇️

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

Components	Coverage Δ
dumpling	53.9957% <ø> (ø)
parser	∅ <ø> (∅)
br	60.9407% <ø> (+20.3765%)	⬆️

[YangKeao]

/retest

[YangKeao]

Now, I think this PR is ready to merge. cc @bb7133 and @CbcWestwolf

[YangKeao]

/hold

I found a bug. If ldapConnectionPool is re-initialized, and an already built ldapAuthImpl is getting a connection from the pool, there'll be a data race 🤦 . Let me fix it.