Add support for ESO API

[fruechel]

This mirrors the changes in https://github.com/rapid7/nexpose-client/pull/309 but limited to discovery connections.

Description

Implement support for ESO API for discovery connections. Based on @hwilson-r7's changes in https://github.com/rapid7/nexpose-client/pull/309

• Add new functions to the client to talk to the ESO API
• Add new functions using the API for management of discovery connections
• Add new JSON HTTP request functions where they differ from their old usage
• Add generic EsoConfiguration class to handle all types of configuration
• Add specific support for AWSConfiguration class to address that particular use case.
• The two changes above both allow for an easy use of the API generically but also to handle AWS much more conveniently. This makes it extensible & it should be extended before using other types of connections.

Looking for feedback on whether this is the way you'd like this implemented or if changes are needed.

Motivation and Context

This API is new and there is no support for it yet. We're looking at using it.

How Has This Been Tested?

I created a test script that runs through most functionality. The following things are known issues:

• Preview does not work, it gives an error 500
• Error handling is not perfect - the client catches an error 500 very far down in the stack but the API will expose proper error messages. Potentially, the API should send 4XX errors as they indicate an error on the clients' side (and a 500 as it's being thrown indicates something the user can't fix). Error messages such as "this already exists" are 4XX but the server returns 500. If the server won't change, this will need updating.

The following things have been tested and work:

• Listing connections, types, etc.
• Saving a new & existing connection
• Deleting a connection
• Testing a connection
• Adding a second region to an existing site (for AWS)
• Everything above has only been tested in the context of AWS but should work generically as far as I can tell

A recent update does also seem to cause 401s unless X-Requested-With: XMLHttpRequest HTTP headers are sent. This seems like a weird bug introduced in 6.4.66 so I didn't include it in the PR, assuming it'll go away once fixed there.

No unit tests have been written.

This is the function used to test things:

    print(client.GetEsoServices())
    print(client.GetEsoConfigurationType('amazon-web-services'))
    configs = client.GetEsoServiceConfigurations('amazon-web-services')
    for config in configs:
        print(config.name, config.id)
    configs = {c.name.lower(): c for c in configs}
    config = client.GetEsoServiceConfigurationByName('amazon-web-services', config.name)
    print(config.name, config.id)
    config = client.GetEsoServiceConfiguration(config.id)
    print(config.name, config.id)
    print(client.TestEsoServiceConfiguration(config))
    print(client.PreviewEsoServiceConfiguration(config))
    config.add_region('Asia Pacific (Sydney)')
    config_id = client.SaveEsoServiceConfiguration(config)
    assert config_id == config.id
    assert config.id
    print(config.name, config.id)
    """
    client.DeleteEsoServiceConfiguration(config)
    print('Deleted config {}'.format(config.id))
    """

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• [ ] I have updated the documentation accordingly (if changes are required).
• [ ] I have added tests to cover my changes.
• [x] All new and existing tests passed.

[fruechel]

I did just realise that the update to 6.4.66 actually pushed out some changes regarding the API. I'm looking at the /integration-options endpoint now, trying to implement it in a user-friendly way. That is, like the UI does, you shouldn't have to manually handle all of these details.