Retry if got empty ldap results for certain response code

What does this MR do?

This MR will do some retries in LDAP search execution if the returned data is empty and with specified response code in LDAP configuration. The implementation it self inspired by Hashicorp's go-retryablehttp.

The background for this implementation, our Gitlab EE in GCP is configured using LDAP sync for users and groups to Google Secure LDAP, but since we have a lot number of users and groups to be synced then it will generating burst of queries that sometime returning empty response by status code 80. We already raise the ticket to Google Workspace Support that confirmed for it's behavior/design.

But the impact in our Gitlab is quite fatal because it will block the user (for ldap user sync) and will clean up all member in a group (for ldap group sync) which can (may) be fixed in next configured sync interval until then users which got this experience will complaining due cannot access Gitlab or some features related to Grouping such as approval, CODEOWNER, etc cannot be used.

So then by retrying it until MAX_SEARCH_RETRIES will prevent the issue happen. Actually the implementation was there for any network connection error but not for empty ldap query results.

Screenshots (strongly suggested)

Got empty result in LDAP group sync that caused emptying group's member.

Some errors once the users massively got blocked in LDAP user sync

User got blocked when got empty results

Does this MR meet the acceptance criteria?

Conformity

• I have included a changelog entry, or it's not needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
• I have tested this MR in all supported browsers, or it's not needed.
• I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.