fix(validation): add handler for idempotencyToken

[flrgh]

The idempotencyToken flag is set on many different API parameter definitions. It has no real implication for validation because API definitions that use it tend to include additional string validation operators for it, such as min/max length and regex match.

I suspect that this field is present as a hint to the SDK that it should generate a UUID if the caller has not specified one, because here's an excerpt from the docs for one of the APIs that accepts such a parameter:

If you use the AWS CLI or one of the AWS SDKs to call this operation,
then you can leave this parameter empty because they generate a random
UUID for you.

See also:

• https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_PutSecretValue.html#SecretsManager-PutSecretValue-request-ClientRequestToken

---

fixes #51

[flrgh]

AWS really loves to make things mildly unintuitive. Their type definitions tend to specify idempotencyToken parameters as optional (example), but in many (most? all?) cases they're only optional from the perspective of the SDK interface; the underlying API requires them.

For example, if I try to send a request to the secrets manager PutSecretValue API without a ClientRequestToken, the SDK doesn't care, but the API throws a 400 response back at me:

{
  "Message": "You must provide a ClientRequestToken value. We recommend a UUID-type value.",
  "__type": "InvalidRequestException"
}

I think a good follow-up action would be to add the proper mechanism to auto-generate a UUID for parameters where idempotencyToken == true, since it seems that is how most official AWS SDKs behave. It will require an additional dependency, but with things like lua-resty-jit-uuid this is relatively painless.

[Tieske]

This looks good. Thx.
Can you please add a changelog entry, similar to this one?