Updates quic_client_bin.cc to be more user friendly, and support more

Updates quic_client_bin.cc to be more user friendly, and support more
options. Deprecates quic_prober.cc in the process as all (used)
functionality now also in quic_client_bin.cc.

Uses std::cout/cerr instead of LOG() statements, and is has hopefully
more easily parseable output (especially for those off-team) than the
previous tool.

Removed the "print_response" argument to QuicClient, instead QuicClient
has accessor's to the latest response code/headers/body if a user wants
to print details (the only user of this feature is quic_client_bin).

Examples of output:

$ quic_client http://www.google.com/ipz --quiet --host=74.125.137.103
Connected to 74.125.137.103:80
Request succeeded (200).

$ quic_client http://www.google.com/invalid --quiet --host=74.125.137.103
Connected to 74.125.196.105:80
Request failed (404).

$ quic_client http://www.example.com --host=93.184.216.34
Failed to connect to 93.184.216.34:80. Error: QUIC_CONNECTION_TIMED_OUT

$ quic_client http://www.google.com/ipz --host=74.125.137.103
Connected to 173.194.37.84:80
Request:
headers:
 :authority: http://www.google.com
 :method: GET
 :path: /ipz
 :scheme: http
body:

Response:headers:
 HTTP/1.1 200 OK
 Content-Length: 13
 content-type: text/html; charset=UTF-8
 date: Tue, 30 Dec 2014 20:34:50 GMT
 server: GFE/2.0
 x-google-backends: acdd12:80
 x-google-gfe-request-trace: acdd12:80
 x-google-gfe-response-code-details-trace: handling_ipz
 x-google-gfe-service-trace:
 x-google-service: _internal

body: 172.26.18.85

Request succeeded (200).

TODO: make --host optional by getting IP Address of URL's host.

Merge internal change: 83518478

R=rch@chromium.org

Committed: https://crrev.com/48fc029001d5e6956ef1a3db2ffe22b74b493a5b
Cr-Commit-Position: refs/heads/master@{#311323}

[ramant (doing other things), 2015-01-13 01:35:47]

https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/quic_clie...
File net/tools/quic/quic_client_bin.cc (right):

https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/quic_clie...
net/tools/quic/quic_client_bin.cc:231:
net::tools::SpdyUtils::RequestHeadersToSpdy4Headers(headers);
rjshade: rch pointed out an issue with RequestHeadersToSpdy4Headers. For
:authority we are sending host_and_port. rch added SPDY4 compression in version
24.

These changes worked ok, but I am not 100% sure if this is correct or not and
why things are working without rch's version 24 change and if we are ready for
SPDY4 or not.

Sorry if I am wrong with what I am asking.

https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/spdy_util...
File net/tools/quic/spdy_utils.cc (right):

https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/spdy_util...
net/tools/quic/spdy_utils.cc:103: block->insert(make_pair(kV4Host,
host_and_port));
rjshade: Is this right? Are we sending SPDY4 headers correctly?

[rjshade, 2015-01-13 15:22:35]

rjshade@chromium.org changed reviewers:
+ rjshade@chromium.org

[rjshade, 2015-01-13 15:22:36]

https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/quic_clie...
File net/tools/quic/quic_client_bin.cc (right):

https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/quic_clie...
net/tools/quic/quic_client_bin.cc:231:
net::tools::SpdyUtils::RequestHeadersToSpdy4Headers(headers);
On 2015/01/13 01:35:47, ramant wrote:
> rjshade: rch pointed out an issue with RequestHeadersToSpdy4Headers. 
> These changes worked ok, but I am not 100% sure if this is correct or not and
> why things are working without rch's version 24 change and if we are ready for
> SPDY4 or not.

This call to RequestHeadersToSpdy4Headers is just so that there's a nice way to
print them out below (line 238,239). If you can iterate over the BalsaHeaders
|headers| object instead then do that, and you don't need the conversion to
Spdy4Headers. Does that make sense?

https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/spdy_util...
File net/tools/quic/spdy_utils.cc (right):

https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/spdy_util...
net/tools/quic/spdy_utils.cc:103: block->insert(make_pair(kV4Host,
host_and_port));
On 2015/01/13 01:35:47, ramant wrote:
> rjshade: Is this right? Are we sending SPDY4 headers correctly?

See my other comment reply, but we aren't actually *sending* anything that is
returned from this function. It's just being used to transform BalsaHeaders into
something that can be easily iterated over and printed to std::cout.

[Ryan Hamilton, 2015-01-13 18:47:14]

On 2015/01/13 15:22:36, rjshade wrote:
>
https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/quic_clie...
> File net/tools/quic/quic_client_bin.cc (right):
> 
>
https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/quic_clie...
> net/tools/quic/quic_client_bin.cc:231:
> net::tools::SpdyUtils::RequestHeadersToSpdy4Headers(headers);
> On 2015/01/13 01:35:47, ramant wrote:
> > rjshade: rch pointed out an issue with RequestHeadersToSpdy4Headers. 
> > These changes worked ok, but I am not 100% sure if this is correct or not
and
> > why things are working without rch's version 24 change and if we are ready
for
> > SPDY4 or not.
> 
> This call to RequestHeadersToSpdy4Headers is just so that there's a nice way
to
> print them out below (line 238,239). If you can iterate over the BalsaHeaders
> |headers| object instead then do that, and you don't need the conversion to
> Spdy4Headers. Does that make sense?
> 
>
https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/spdy_util...
> File net/tools/quic/spdy_utils.cc (right):
> 
>
https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/spdy_util...
> net/tools/quic/spdy_utils.cc:103: block->insert(make_pair(kV4Host,
> host_and_port));
> On 2015/01/13 01:35:47, ramant wrote:
> > rjshade: Is this right? Are we sending SPDY4 headers correctly?
> 
> See my other comment reply, but we aren't actually *sending* anything that is
> returned from this function. It's just being used to transform BalsaHeaders
into
> something that can be easily iterated over and printed to std::cout.

Hah! Nice. We both totally missed that last night. Good point.

LGTM

[ramant (doing other things), 2015-01-13 20:10:09]

The CQ bit was checked by rtenneti@chromium.org

[commit-bot: I haz the power, 2015-01-13 20:10:51]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/847813005/20001

[ramant (doing other things), 2015-01-13 20:11:15]

On 2015/01/13 18:47:14, Ryan Hamilton wrote:
> On 2015/01/13 15:22:36, rjshade wrote:
> >
>
https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/quic_clie...
> > File net/tools/quic/quic_client_bin.cc (right):
> > 
> >
>
https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/quic_clie...
> > net/tools/quic/quic_client_bin.cc:231:
> > net::tools::SpdyUtils::RequestHeadersToSpdy4Headers(headers);
> > On 2015/01/13 01:35:47, ramant wrote:
> > > rjshade: rch pointed out an issue with RequestHeadersToSpdy4Headers. 
> > > These changes worked ok, but I am not 100% sure if this is correct or not
> and
> > > why things are working without rch's version 24 change and if we are ready
> for
> > > SPDY4 or not.
> > 
> > This call to RequestHeadersToSpdy4Headers is just so that there's a nice way
> to
> > print them out below (line 238,239). If you can iterate over the
BalsaHeaders
> > |headers| object instead then do that, and you don't need the conversion to
> > Spdy4Headers. Does that make sense?
> > 
> >
>
https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/spdy_util...
> > File net/tools/quic/spdy_utils.cc (right):
> > 
> >
>
https://codereview.chromium.org/847813005/diff/20001/net/tools/quic/spdy_util...
> > net/tools/quic/spdy_utils.cc:103: block->insert(make_pair(kV4Host,
> > host_and_port));
> > On 2015/01/13 01:35:47, ramant wrote:
> > > rjshade: Is this right? Are we sending SPDY4 headers correctly?
> > 
> > See my other comment reply, but we aren't actually *sending* anything that
is
> > returned from this function. It's just being used to transform BalsaHeaders
> into
> > something that can be easily iterated over and printed to std::cout.
> 
> Hah! Nice. We both totally missed that last night. Good point.
> 
> LGTM

Thanks Ryan and Robbie. Would like to submit the CL by itself because it is more
of porting rather than simple merge

[commit-bot: I haz the power, 2015-01-13 21:09:41]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-01-13 21:10:41]

Patchset 2 (id:??) landed as
https://crrev.com/48fc029001d5e6956ef1a3db2ffe22b74b493a5b
Cr-Commit-Position: refs/heads/master@{#311323}