Python-opsramp

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.

This base class now provides centralized boilerplate versions of the most common REST methods so that subclasses can just use those if they don't need anything special. Previously it only supported GET but this adds POST, PATCH, PUT, DELETE.