Move all HTTP calls to a dedicated class and use Jetty HTTP client instead of raw HttpUrlConnection

[nikita-tkachenko-datadog]

Requirements for Contributing to this repository

• Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• The pull request must only fix one issue at the time.
• The pull request must update the test suite to demonstrate the changed functionality.
• After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING.

What does this PR do?

This PR does a few improvements to the way the plugin does HTTP calls, making them more efficient and limiting the number of concurrent requests.

The reason to do this is that there is a customer with a Jenkins instance that runs multiple large pipelines: when executed with the plugin enabled, the process runs out of available file descriptors because the requests are slow (since each one opens a new TCP socket) and because there is no limit on the number of simultaneous requests and no backpressure if the network layer cannot keep up.

Description of the Change

• all the HTTP calls are now delegated to org.datadog.jenkins.plugins.datadog.clients.HttpClient which provides a layer of abstraction on top of HTTP-calling logic
• Jetty HTTP client is now used instead of raw HttpUrlConnection, which allows to pool and reuse TCP sockets, limit the number of simultaneous requests and to make some of the request asynchronously
• Retry logic is added to re-execute calls that are failing

Alternate Designs

Possible Drawbacks

Verification Process

Verified manually in Agentless/Evp-proxy/Agentful-APM modes. Separate set of verifications is done with Jenkins using an HTTP proxy (to ensure the plugin respect Jenkins' proxy settings).

Additional Notes

Release Notes

Review checklist (to be filled by reviewers)

• [ ] Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
• [ ] PR title must be written as a CHANGELOG entry (see why)
• [ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
• [ ] PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
• [ ] PR should not have do-not-merge/ label attached.
• [ ] If Applicable, issue must have kind/ and severity/ labels attached at least.

[nikita-tkachenko-datadog]

I think this PR needs to be reviewed by the jenkins-plugin team as well, as AFAIK we wanted to use vanilla Java HTTP classes to avoid affecting Jenkins core with external dependencies.

Jenkins plugins are loaded using isolated classloaders, so including a third-party dependency in a plugin has no effect on Jenkins core. Plugin classloaders are children of the classloader that is used to load the core, so the worst that can happen in theory is a problem in the plugin in case it tries to load a class that is already available in the core loader (because children CLs delegate to parent CL). Anyway, this is not the case here, since neither Jenkins core nor the plugins that we depend on use Jetty HTTP.