Add support to request for compressed payloads from the HRavenRestClient

[piyushnarang]

Noticed that even with counter filtering (#160), some of our payloads are multiple MB in size. The hraven server seems to support gzip as an accept-encoding option and when we use that it compresses the payload substantially in some cases (e.g. one call when down to 32K from 1.45MB). Can observe this behavior via curl:

curl -v --output /dev/null  -H "Accept-Encoding: gzip" -X GET  "http://hraven.devel.host/api/v1/tasks/procrev@atla/job_1486504431708_30155?include=taskType&include=taskId"

> GET /api/v1/tasks/procrev@atla/job_1486504431708_30155?include=taskType&include=taskId HTTP/1.1
> Host: hraven.devel.host
> User-Agent: curl/7.51.0
> Accept: */*
> Accept-Encoding: gzip
> 
  0     0    0     0    0     0      0      0 --:--:--  0:00:07 --:--:--     0< HTTP/1.1 200 OK
< Content-Type: application/json
< Server: Jetty(6.1.26)
< Content-Encoding: gzip
< Content-Length: 32677

I updated the UrlDataLoader to use the apache HTTP libraries. The libraries are setup to use Accept-encoding = "gzip,deflate" by default. In case users of HRavenRestClient explicitly want to not use compression, they can opt out.
Tested the code out with compression on and off.

[coveralls]

Coverage decreased (-0.003%) to 2.148% when pulling bf21fae on piyushnarang:client-gzip into e17ec79 on twitter:master.

[dieu]

let's move it to debug.

[piyushnarang]

sure

[vrushalivc]

Yes, chatted with Piyush offline. We can change the default one using compression to debug mode and keep the "not using compression" in info mode

[coveralls]

Coverage decreased (-0.03%) to 2.124% when pulling 111167f on piyushnarang:client-gzip into e17ec79 on twitter:master.

[vrushalivc]

Thanks @piyushnarang