Improve handling of partially parseable query strings

Previously we assumed that if qs.stringify didn't match the query
string, then the queryString & queryObj properties would be empty, and
so leaving the querystring in the URL (basically disabling structured
generation of query = { a: b } style code and using raw URLs instead)
would be safe.

It turns out though that for partially parseable cases, we can get HARs
with a URL containing a broken query string _and_ a valid queryString
property with some values in it. We now actively ignore the latter, so
the URL as always used as-is.

Author: pimterry

src/index.js

@@ -242,9 +242,11 @@ HTTPSnippet.prototype.prepare = function (request) {
       request.uriObj.path = request.uriObj.pathname + '?' + request.uriObj.search
     }
   } else {
-    // We have no request.queryObj (so snippets won't send query params in a structured way)
-    // We keep the queryString in request.url (so it's sent raw everywhere)
+    // We keep the queryString in request.url (so it's sent raw everywhere) but disable it
+    // elsewhere, so it's omitted from automatic code generation cases.
     // request.fullUrl is recreated below (maybe mild fixed?) but preserves raw search etc
+    request.queryString = []
+    request.queryObj = {}
   }
 
   // construct a full url

test/fixtures/requests/unparseable-query.json

@@ -1,6 +1,11 @@
 {
   "method": "GET",
   "url": "http://mockbin.com/har?&&a=b&&",
-  "httpVersion": "HTTP/1.1",
-  "queryString": []
+  "queryString": [
+    {
+      "name": "a",
+      "value": "b"
+    }
+  ],
+  "httpVersion": "HTTP/1.1"
 }