Update endpoint discovery resolver to handle explicit service URLs

[dscpinheiro]

Fixes #3349

Motivation and Context

Timestream is one of two services (along with DynamoDB - see notes below) where the SDK attempts to perform dynamic endpoint discovery (important: this is not related to the endpoint resolution change introduced in version 3.7.100). A longer explanation is available in the developer guide, but in summary endpoint discovery works like this:

1. If the requested operation requires endpoint discovery, the SDK calls the DescribeEndpoints API to fetch which endpoints customers should use (Timestream uses a cellular architecture so each customer is mapped to a specific cell)
2. The SDK caches the returned endpoint and uses it for future invocations (refreshing it in the background)

One unusual thing about Timestream is that the DescribeEndpoints API can only be invoked via the regional endpoints (from usage notes). If customers create a VPC endpoint for Timestream and try to use its URL in the service client the operation fails (as the SDK attempts to perform endpoint discovery against an endpoint that doesn't support it).

var client = new AmazonTimestreamQueryClient(new AmazonTimestreamQueryConfig
{
    ServiceURL = "https://query-cell1.timestream.us-west-2.amazonaws.com"
});

// This will fail since the SDK attempts to call "DescribeEndpoints" behind the scenes.
await client.QueryAsync(...);

This PR updates the EndpointDiscoveryResolver not to attempt endpoint discovery if there's a service URL set in the current client config.

Testing

• Dry-run: de91537f-92a8-4cc2-ba8a-2a93653ff0dd
• Ran the console app mentioned in the original issue in a private EC2 instance (i.e. no internet access)

The outputs below are from the application setting the ServiceURL property; behaviour will not change when using RegionEndpoint instead.

Before:

Amazon Error: 4 : 
  AmazonClientException making request QueryRequest to https://query-cell1.timestream.us-west-2.amazonaws.com/. 
  Attempt 1., Amazon.Runtime.AmazonClientException: Failed to discover the endpoint for the request. 
  Requests will not succeed until an endpoint can be retrieved or an endpoint is manually specified.

Error querying Timestream: Failed to discover the endpoint for the request. 
Requests will not succeed until an endpoint can be retrieved or an endpoint is manually specified.

After (connection succeeded without attempting to call DescribeEndpoints):

Amazon Verbose: 0 : Received response (truncated to 1024 bytes): 
[
    {
        "ColumnInfo": [...],
        "QueryId": "",
        "QueryStatus": {},
        "Rows": [...]
    }
]

Notes

• There's an environment variable / option to turn off endpoint discovery, but the resolver initially checks whether the operation requires it (which is the case for Timestream):

  aws-sdk-net/sdk/src/Core/Amazon.Runtime/Internal/EndpointDiscoveryResolver.cs

  Lines 94 to 100 in 0d195b2

  	//Determine if we are required to get an endpoint or if we can defer it to an async call
  	if (context.EndpointDiscoveryData.Required)
  	{
  	//Must find an endpoint or error for this operation
  	endpoints = ProcessInvokeEndpointOperation(cacheKey, InvokeEndpointOperation, true);
  	}
  	else if (_config.EndpointDiscoveryEnabled)

• DynamoDB is the other service with endpoint discovery, but unlike Timestream it's marked as optional:

  aws-sdk-net/generator/ServiceModels/dynamodb/dynamodb-2012-08-10.api.json

  Lines 489 to 490 in 0d195b2

  	"endpointdiscovery":{
  	}

I couldn't find reports of the same issue happening with DynamoDB, my assumption is that endpoint discovery just isn't a common setup. DynamoDB also supports gateway endpoints, which in addition to being free of charge don't require setting a custom service URL (traffic is routed using prefix lists instead).

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist

• My code follows the code style of this project
• I have read the README document
• I have added tests to cover my changes
• All new and existing tests passed

License

• I confirm that this pull request can be released under the Apache 2 license

[muhammad-othman]

nit: Using !string.IsNullOrEmpty(config.ServiceURL) here seems more straight forward instead of creating a property that isn't used anywhere else (yet).

[dscpinheiro]

Ack, I ended up creating a new property since this resolver class wasn't saving the config object (and that seemed the simpler option).