I am not sure if this is the best way to go about this, but I'm opening this PR to see if you think this is a good idea. Basically, the problem I am trying to solve is that some REST APIs I am trying to test have certain combinations of parameters that are valid. This means that the current approach of filling in all the parameters that are discovered in each operation won't work, as the testing never gets past the validation phase.

My solution to this: add an extension field to the operation in the Open API spec, that if present will further refine the request that w3af creates. A good example is in the test case I added, but basically the extension parameter x-w3af-request-templates contains a list of overrides to the operation it is contained in. When this is encountered, each override is applied, and a separate fuzzable request is generated for each one.

As an example, say I have an API that is available at http://www.example.com/products/search. This API can take exactly one query string parameter from the set of {name, description, price} to search by the specified parameter. If you specify a search by multiple criteria a validation error will occur. Right now there's no way to teach w3af about this (or many other restrictions that are described in text but not expressible in swagger like dependencies between parameters, etc). With this change I can write something like:

<snip>
"/products/search": {
  "get": {
    "parameters": [
      <definition for name, required=false>,
      <definition for description, required=false>,
      <definition for price, required=false>
    ],
    "x-w3af-request-templates": [
      {"parameters": [<definition for name, required=true>]},
      {"parameters": [<definition for description, required=true>]},
      {"parameters": [<definition for price, required=true>]}
    ]
  }
}

to teach w3af about the combinations of parameters that can work together.