support validating requests, responses against callbacks and webhooks - split up find_path usecases

[karenetheridge]

Most of the request and response validation can be applied equally well to descriptions in callbacks and webhooks -- just the initial bit where we take the request and call find_path on it to match the request URI against entries in /paths/{path description} doesn't apply here.

So, pull out the meat of the validation into separate subs which are called by multiple entry points - some of which would not require a path template for matching (instead, the inner sub takes the path-item location, which could be calculated by find_path or could be supplied directly, e.g. by an earlier call of validate_request that is processing a callback section.

[karenetheridge]

This will make it possible to call validate_response with just an operation_id, or path_item_path + http method. We don't care about the path template or path captures variables as they are not used for responses.

[karenetheridge]

In version 0.068, it is now possible to call validate_response purely by operation_id, without providing a request or providing a path_template value. This can be used to validate responses associated with a callback or webhook.

However, callback requests and webhook requests are not yet recognized by validate_request, as the request is still matched against path templates in /paths/*.

• add boolean webhook and callback parameters to the options hash, to allow the caller of validate_request, validate_response or find_path to indicate that the entity being validated does not correspond to an API under /paths/* but rather an out-of-band webhook. This would require the use of operation_id to actually find the operation in question in order to validate against it.

• for callbacks, things get more interesting, as we also would like to validate the individual parameters used in the callback definition... in this case, we need to have the original request that was used to initiate the callback, as that's what the templated parameters are expanded against... This should be pulled off into its own task (along with some helpers that can evaluate these templates, e.g. for request composition).