adds support for OPTIONS method

[fanny-jiang]

What does this PR do?

Adds support for the OPTIONS HTTP method to the RequestsWrapper

Motivation

Support case

Additional Notes

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• 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 changelog/ and integration/ labels attached

[codecov]

Codecov Report

Merging #7804 into master will decrease coverage by 2.73%.
The diff coverage is n/a.

Impacted Files	Coverage Δ
pgbouncer/datadog_checks/pgbouncer/metrics.py	100.00% <0.00%> (ø)
consul/datadog_checks/consul/__about__.py	100.00% <0.00%> (ø)
..._controller/tests/test_nginx_ingress_controller.py	100.00% <0.00%> (ø)
http_check/tests/test_unit_utils.py	100.00% <0.00%> (ø)
go_expvar/tests/test_unit.py	100.00% <0.00%> (ø)
apache/tests/test_apache.py	91.66% <0.00%> (ø)
marathon/tests/common.py	100.00% <0.00%> (ø)
nginx/tests/common.py	100.00% <0.00%> (ø)
etcd/tests/utils.py	100.00% <0.00%> (ø)
consul/tests/test_integration.py	98.24% <0.00%> (ø)
... and 353 more

[FlorianVeaux]

Looks good

Can we split this PR into 3 though? One for datadog_checks_base, one for datadog_checks_dev and lastly one for the http_check integration?

Also in-between we'll want to release datadog_checks_base and bump the datadog_checks_base dependency for http_check

[FlorianVeaux]

Let's name that options to match how requests names it

[fanny-jiang]

Thanks for taking a look Florian! I named it options_method so that it wouldn't conflict with the self.options that already exists and cause a TypeError: 'dict' object is not callable:

integrations-core/datadog_checks_base/datadog_checks/base/utils/http.py

Lines 259 to 266 in 2b3d4c9

	self.options = {
	'auth': auth,
	'cert': cert,
	'headers': headers,
	'proxies': proxies,
	'timeout': (connect_timeout, read_timeout),
	'verify': verify,
	}

Are there ways I can follow convention and name it options without conflicting with self.options or should I keep it as is? I considered re-naming self.options, but I was concerned about re-naming it across the codebase and introducing bugs. Let me know what you think.

[FlorianVeaux]

Hadn't thought of that, that's a bit unfortunate and we'd have to rename options in integrations as well + custom checks may rely on this. So let's go with options_method then.