Attempt to fix flaky Harbor E2E setup

[NouemanKHAL]

What does this PR do?

The Harbor E2E tests failed recently with the following error:

E           datadog_checks.dev.errors.RetryError: Result: None
E           Error: HTTPConnectionPool(host='localhost', port=80): Max retries exceeded with url: /api/v2.0/users/ (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7ff4b4ff1f70>: Failed to establish a new connection: [Errno 111] Connection refused'))
E           Function: create_simple_user, Args: (), Kwargs: {}

This PR tries to address that issue by increasing the wait time giving more time for the harbor users endpoint to be healthy.

Motivation

Failing job: https://github.com/DataDog/integrations-core/actions/runs/16020744131/job/45196949202

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Add the qa/skip-qa label if the PR doesn't need to be tested during QA.
• If you need to backport this PR to another branch, you can add the backport/<branch-name> label to the PR and it will automatically open a backport PR once this one is merged

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.04%. Comparing base (0cc4a1c) to head (f0ad2b8).

Additional details and impacted files

Flag	Coverage Δ
activemq	?
cassandra	?
confluent_platform	?
harbor	89.04% <ø> (-0.61%)	⬇️
hive	?
hivemq	?
hudi	?
ignite	?
jboss_wildfly	?
kafka	?
presto	?
solr	?
tomcat	?
weblogic	?

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[AAraKKe]

Is there a reason to believe that one more second is enough? Just curious.

[NouemanKHAL]

class WaitFor(LazyFunction):
    def __init__(
        self,
        func,  # type: Callable
        attempts=60,  # type: int
        wait=1,  # type: int
        args=(),  # type: Tuple
        kwargs=None,  # type: Dict
    ):

This is actually increasing the waiting time by 4 seconds for every attempt (60 by default)

[AAraKKe]

Oooh true, I checked how WaitFor works but missed that the sleep in there is in each loop. Seems a crazy increase though we will go from 64 to 240 seconds max haha, hopefully 4 minutes is enough.

[NouemanKHAL]

I figured it's pointless to increase it just a bit every time it fails, I'd rather wait as much possible cause we have no choice, if it still fails with this big timeout, then we have a different problem, we might need to consider switching to exponential retry backoff