(TK-29) Add support for query parameters

[MSLilah]

This PR adds support for query parameters to both the Java and clojure clients.

With the Java client, setting Query Parameters works the same way it did before the port to AsyncHttpClient.

With the clojure client, query parameters are set with a new :query-params option in the options map passed to a request. Query parameters can be set either in the URL or with this new option. However, if the query parameters are set with this new option AND in the URL, all parameters set directly in the URL will be removed, and only the ones specified in the options map will be sent as parameters.

[KevinCorcoran]

:+1:

[MSLilah]

@KevinCorcoran I've addressed your comment

[camlow325]

Maybe it would be too late to do this now and maintain compatibility but I think it would be better for the RequestOptions Java class to require the caller to specify an instance of a java.net.URIclass -- in calls to the constructor and on the getUrl() and setUrl() methods. That way, we wouldn't need to have a separate set of accessors for query params and all of the ambiguity around how query parameters would be handled when included in both the string argument to the constructor and the accessor methods would go away.

[camlow325]

:+1: overall although I would like to get some feedback on a few points:

• Should the RequestOptions Java class operate only on java.net.URI objects in its public method signatures rather than String in order to help manage some of the ambiguity / complexity that would otherwise be introduced by separate query params accessor methods?
• Couple of extra tests suggested for the Java client, which may change based on the outcome of the discussion for the first point.

[KevinCorcoran]

@camlow325 - I think that's a good idea. I was also surprised when I looked at RequestOptions.url and found it to be a String.

Also, I don't think we need to worry about backwards-compatibility.

[MSLilah]

@camlow325 @KevinCorcoran I believe your comments have been addressed.

[camlow325]

:+1: with a few trailing comments:

• Could simplify the HTTP method calls which take in a String parameter in the AsyncHttpClient and HttpClient classes to use peer methods which take in a URI parameter.
• Could remove a few apparently unused imports in the JavaClient class.
• Could be good to have the CoercedRequestOptions class operate on a URI type instead of a String for the URL so that the code doesn't end up having to convert a URI to a String only to be converted back to a URI again in the Apache library anyway.

[MSLilah]

@camlow325 I've addressed your comments.

[camlow325]

:+1: