Python-opsramp

Allow the user to supply a customized requests session object if they need to.

This is an advanced use case because in general we would not want the caller to subvert us by using the requests module directly; it's effectively an implementation detail. However session objects do sometimes need to be built specifically for the use case in hand, so we should allow that.

Minor bugfix for a URL that had incorrect capitalization. Learning from this, we have set all unit tests to be case-sensitive by default to catch similar problems that might arise in the future.

The constant DEFAULT_ALLOWED_METHODS is only available in very new versions of urllib3 but the equivalent data can be obtained in a different way on older versions. Change the code in base.py to add a fallback that uses the old method if DEFAULT_ALLOWED_METHODS doesn't exist. Consequently we can roll back the requirement for very new requests and urllib3 versions because this removes that need.

Field experience with v1.2.1 has shown that urllib3 1.26 is also needed for POST retries, so update the requirements file accordingly. Also modify the unit test script to run "pip freeze" so that we log a record of the versions that were used in CI.

Field experience with v1.2.0 has shown that requests 2.25.0 is needed for POST retries, so update the requirements file accordingly.

OpsRamp recently tightened up their API call rate limits so HTTP 429 "rate limiting" responses from the server happen more often. This module already handles server rate limiting, and has for a long time, so these limit changes should be transparent to the caller (although the retry handlers will probably get exercised more now under the hood).

Previous versions of this module did not retry on POST errors though. This matches the default behavior of the standard Python urllib3 module, because the thinking is that POST is not idempotent and therefore retry could have unwanted side-effects like creating multiple new objects instead of just one.

However the OpsRamp rate limit on POST operations is very low indeed so we have had to revisit that position because it places the onus on the caller to handle all POST errors. In the specific case of rate-limiting error codes, the advice from OpsRamp is that we can assume the POST did not take place and therefore it is safe to retry the operation. Therefore this version of python-opsramp DOES retry on POST if and only if the failure was due to rate limiting.