Set default parameter location based on consumes

[spaceraccoon]

As per #721, grape-swagger sets the default consumes to ['application/json'] in lib/grape-swagger/doc_methods/produces_consumes.rb:

return ['application/json'] unless args.flatten.present?

However, it also sets the default in of parameters to formData in lib/grape-swagger/doc_methods/parse_params.rb:

def document_array_param(value_type, definitions)
...
  @parsed_param[:in] = param_type || 'formData'

def param_type(value_type)
...
  elsif %w[POST PUT PATCH].include?(value_type[:method])
    DataType.request_primitive?(value_type[:data_type]) ? 'formData' : 'body'

Here, DataType.request_primitive simply checks if the parameter's data type is one of integer long float double byte date dateTime binary password email uuid object string boolean file json array, in which case its location is set to formData. As such, this leads to a situation where most parameters are set to formData by default while their endpoint is also set to consumes application/json by default:

      consumes:
        - application/json
      parameters:
        - in: formData

However, as described in the OpenAPI V2 documentation (also here), the payload of the application/x-www-form-urlencoded and multipart/form-data requests is described by using form parameters, not body parameters and formData should only be used for application/x-www-form-urlencoded and multipart/form-data requests. Currently, the default output of grape-swagger will lead to OpenAPI validation errors.

This MR adds logic to set the default parameter location (in) based on the consumes object, setting it to formData if consumes is application/x-www-form-urlencoded or multipart/form-data and body if otherwise for PUT POST PATCH requests. This can still be overriden by endpoint-specific options as is the usual behaviour.

However, since several specs relied on this invalid output previously, it is necessary to make some changes to ensure passing.

[dhruvCW]

@spaceraccoon & @LeFnord any chance we could merge this change ?

If you folks would prefer I can open a separate PR to rebase this change onto master.

[dhruvCW]

this can be closed since the changes have been merged with #927