Add Route53 ID customization to Botocore.

[danielgtaylor]

This change moves and adds to the customization currently in the AWS CLI
that handles automatically splitting Route53 resource IDs.

For example, /hostedzone/ABC123 will be changed to just ABC123 when
used as input to a Route53 service operation. The Id, HostedZoneId,
ResourceId, and DelegationSetId input parameters are all handled by
this customization. We do not need to handle HealthCheckId because the
format is different and as such it doesn't have this issue.

This fixes an issue encountered in boto/boto3#28.

A corresponding change will need to be made to the AWS CLI to remove the
customizations there after this is merged in.

cc @jamesls, @kyleknap

[jamesls]

This is handling more cases that what the CLI customization does. Can you verify that:

a) these cases are necessary (is there a sample output you can show)?
b) this won't result in a change in behavior in the CLI?

[danielgtaylor]

It isn't obvious but it's actually handling the same cases. The CLI customization is getting a parameter object which corresponds to the shape of the parameter. The Id and HostedZoneId parameters are of type ResourceId, which is what value is in param.name. Since Botocore doesn't expose such information, I instead opted to check all of the known names that resolve to a ResourceId shape, which means we need to check for two additional items.

a) For example (this is just one of a handful of methods that need this change):

import boto3
route53 = boto3.client('route53')
route53.get_hosted_zone(Id='hostedzone/abcd1234')

Before the fix we would get ClientError: An error occurred (400) when calling the GetHostedZone operation: Bad Request. This becomes important when implementing resources, which create request parameters from response data. In the example above, the Id parameter would be set from the response to a list call, hence the need for the transformation.

b) The behavior should be backward-compatible, and I have run all existing unit/integ tests and have manually made several calls to Route53 using the updated Botocore and affected parameter names. Everything has worked for me both with the long form (/hostedzone/abc123) and short form (abc123).

[jamesls]

This becomes important when implementing resources, which create request parameters from response data. In the example above, the Id parameter would be set from the response to a list call, hence the need for the transformation.

Yeah I'm not saying we don't this change, I'm just confirming that this is an actual port of the CLI customization and won't result in regressions.

The CLI customization is getting a parameter object which corresponds to the shape of the parameter. The Id and HostedZoneId parameters are of type ResourceId, which is what value is in param.name.

Ah ok, that makes sense. I didn't write the original route53 customization, but I'm pretty sure the reason it was done that way is that we won't have to update the customization when a route53 API update decides to use this shape again in a new param name. It seems like with this approach we will, and seems like this is something that will easily be missed.

If this is the case, can we figure out a way so we don't have to update the customization as new params are added to the API?

[danielgtaylor]

@jamesls please take another look. I've changed the implementation to use the operation model's input shape members. It now handles all the same cases by just checking the shape names against the two cases in the CLI customization.

[coveralls]

Coverage increased (+0.04%) when pulling a3d1128 on danielgtaylor:route53-builtin-handler into a3f026e on boto:develop.

[jamesls]

Thanks for updating.