Make the OpsRamp api token available as a property

Make it possible for the caller to get direct access to the OpsRamp API token. This is to support a few use cases in the field where access to the token is needed, or at least useful. People have been using unsupported hacks to get to it. Provide an approved method to counter this.

Functionally identical to v3.4.3 but we have had feedback that this should have been tagged v3.5 per semantic versioning rules, which I agree with "MINOR version when you add functionality in a backward compatible manner"

Beginning of KB functionality revamp

What's Changed

• Fix articlesList bug, update sample by @jofegan in #143
• Improvements to GitHub CI by @jofegan in #140
• Try to build the docker container in GitHub CI by @jofegan in #141
• We are losing access to CircleCI so remove it. by @jofegan in #142
• Move actions/checkout forward to latest version by @jofegan in #144

Full Changelog: v3.4.1...v3.4.2

Move to Python 3.9 for Dockerfile and CI

What's Changed

• Remove "<", ">" from default uninstallReason by @MRawlings in #137
• New sample to list KB category contents by @jofegan in #138
• 2024 Dockerfile updates & Python 3.9 by @jofegan in #139

Full Changelog: v3.4.0...v3.4.1

Support for OpsRamp V2.0 tenancy OAuth2 changes

OpsRamp V2 api requires us to use a tenancy API to log in so changes to accommodate that.
Also some small changes to allow for newer versions of tox and Python test tools.

Add retry support on auth failure

Add capability to retry requests transparently in the event of a transient auth failure that occurs despite having a valid auth token.

Resource groups update bugfix

Bug fix, resource groups update uuid parameter should be embedded in the JSON not in the URI

Handle new search results variant

More interesting OpsRamp behavior. Some search api endpoints
return an empty string if there are no results, instead of a proper
json response containing a list of zero results. Deal with it.

CI and build updates for PEP517, Black, Import ordering

Minor functionality changes including the addition of resource_groups. But the main changes here are refactoring to use Black code formatting and enforce an ordering on the import statements. These are not functional changes and should be a no-op from a user perspective.

Move to pyproject.toml PEP517/PEP518 packaging

Refactor the Python packaging in line with current recommendations.
No functional changes but I am moving to a new minor version nonetheless
because this changes potentially affects installation of the package,
particularly on older systems.

OK is not the only HTTP success

Anything in the range 200-299 is a successful result and in particular POST operations often return http CREATED or NO_CONTENT if there is no need to communicate anything except that the POST succeeded.