Add configurable error status codes to httprb and httpclient

[caramcc]

What does this PR do?
Adds the ability to configure which HTTP status codes are considered errors for http.rb and httpclient as a follow-up to #2501 which added this option to Net/HTTP.

Motivation
The applications I'm instrumenting make a lot of API calls to external services using a few different HTTP libraries, including http.rb and httpclient. Since the services are user-configured, we expect a relatively large volume of these requests to fail with 4xx or 5xx status codes. As a result, we end up ingesting a lot of traces due to ingestion_reason:error that we don't consider to be an error and don't otherwise care about.

Adding the ability to configure which HTTP status codes are considered errors will allow us to reduce our ingestion rates without entirely ignoring all http.rb or httpclient spans that return a 4xx or 5xx status code.

Additional Notes
Let me know if you'd prefer I split the change for httpclient into a separate PR.

This uses the same shared specs and configuration pattern from my previous PR (#2501) which added this feature to Net/HTTP.

How to test the change?
I tested the changes with bundle exec appraisal ruby-3.0.4-contrib rake spec:httprb and bundle exec appraisal ruby-3.0.4-contrib rake spec:httpclient

[TonyCTHsu]

👋 @caramcc, Thanks for the contribution, the PR looks 👍 .

We usually want environment variables for each contrib, by prefixing DD_TRACE_#{contrib}_..... We would appreciated some specs for picking up the environment variable to configure error codes.

Last time I checked, your PR contains the config file but I was not quite sure that why CircleCI refused to run your PR. Perhaps you could rebase on latest master?

[TonyCTHsu]

The value should be 'DD_TRACE_HTTPRB_ERROR_STATUS_CODES'

[TonyCTHsu]

The value should be 'DD_TRACE_HTTPCLIENT_ERROR_STATUS_CODES'

[caramcc]

Last time I checked, your PR contains the config file but I was not quite sure that why CircleCI refused to run your PR. Perhaps you could rebase on latest master?

Just made the requested changes and rebased on latest master, but rebasing doesn't seem to have helped with this unfortunately.

I noticed this issue with my previous PR as well, I'd assumed that those OAuth permissions are set to prevent people from outside the Datadog organization from running CI/CD for security purposes, could that be what's going on here?

[TonyCTHsu]

I noticed this issue with my previous PR as well, I'd assumed that those OAuth permissions are set to prevent people from outside the Datadog organization from running CI/CD for security purposes, could that be what's going on here?

There was CircleCI security breach recently and a lots of security measurements were taken. There were other external contributor successfully submitted PR and have CircleCI run for them. Could you follow this guide to revoke your CircleCI credentials in GitHub and then re-authenticate?

If the issue still persist, I could force push your branch to trigger the build.

[ivoanjo]

On top of what Tony said, after you follow the CircleCI steps, you'll probably need to do another push to get CircleCI to retry. (It otherwise seems to cache the failure state)

Thanks for the patience with CI things :)