Like in synchronous programming, in makes sense to start an inactivity timer only when the caller
does a "recv" call and cancel the timer as soon as data is received from the socket.

This avoids plenty of connection inactivity timeouts. From a logical point of view,
the inactivity timeout should be reset not only only data is received from the socket
but also when the client asks for more data.

Currently ibrowse defined the nodelay socket option to true, not allowing the caller
to supply its own value, which would also make the sndbuf option useless if the caller
supplied it as well.
When sending large bodies, setting nodelay to false with a custom sndbuf can improve
network throughput very significantly. For e.g., custom tests reduced an upload from
16 minutes to about 12 minutes.

Allow chunks to be IO lists. These lists will get flattened by the ERTS in
a much more efficient way than converting them to raw binaries in Erlang code.

When reusing the same connection (ibrowse worker) for multiple requests, the current
inactivity timeout must be cleared before sending a request body. When the sending of the
body takes more than inactivity_timeout milliseconds, the client will get
a req_timedout error. Currenty inactivity_timer is cleared only after sending the whole body.

do_setopts/3 was being called with the 3rd arg as a boolean instead of the "State".

1) Set Content-Length to 0 for empty PUT and POST requests (necessary for some proxies);

2) Use iolist_size/1 instead of size/1 or length/1 because the body can be an iolist

encoding/decoding code in ibrowse_lib.erl and ibrowse_http_client.erl.

OTP's base64 module is also more efficient (C implementation):

1> Data = crypto:rand_bytes(4096).
<<205,174,13,169,97,159,110,161,71,43,226,153,42,101,243,
  83,11,96,23,161,253,251,129,240,163,216,58,175,190,...>>
2>
2> timer:tc(ibrowse_lib, encode_base64, [Data]).
{2920,
 <<"za4NqWGfbqFHK+KZKmXzUwtgF6H9+4Hwo9g6r77h2EF1/Xk1oKOIOmnAkgtv41LPXg37fp2dlr45C8qCA9/8zrcc9F5zr2JT0eVPTrh5aahl"...>>}
3> timer:tc(ibrowse_lib, encode_base64, [Data]).
{1221,
 <<"za4NqWGfbqFHK+KZKmXzUwtgF6H9+4Hwo9g6r77h2EF1/Xk1oKOIOmnAkgtv41LPXg37fp2dlr45C8qCA9/8zrcc9F5zr2JT0eVPTrh5aahl"...>>}
4> timer:tc(ibrowse_lib, encode_base64, [Data]).
{1436,
 <<"za4NqWGfbqFHK+KZKmXzUwtgF6H9+4Hwo9g6r77h2EF1/Xk1oKOIOmnAkgtv41LPXg37fp2dlr45C8qCA9/8zrcc9F5zr2JT0eVPTrh5aahl"...>>}
5> timer:tc(ibrowse_lib, encode_base64, [Data]).
{1195,
 <<"za4NqWGfbqFHK+KZKmXzUwtgF6H9+4Hwo9g6r77h2EF1/Xk1oKOIOmnAkgtv41LPXg37fp2dlr45C8qCA9/8zrcc9F5zr2JT0eVPTrh5aahl"...>>}
6>
6> timer:tc(base64, encode, [Data]).
{1846,
 <<"za4NqWGfbqFHK+KZKmXzUwtgF6H9+4Hwo9g6r77h2EF1/Xk1oKOIOmnAkgtv41LPXg37fp2dlr45C8qCA9/8zrcc9F5zr2JT0eVPTrh5aahl"...>>}
7> timer:tc(base64, encode, [Data]).
{743,
 <<"za4NqWGfbqFHK+KZKmXzUwtgF6H9+4Hwo9g6r77h2EF1/Xk1oKOIOmnAkgtv41LPXg37fp2dlr45C8qCA9/8zrcc9F5zr2JT0eVPTrh5aahl"...>>}
8> timer:tc(base64, encode, [Data]).
{737,
 <<"za4NqWGfbqFHK+KZKmXzUwtgF6H9+4Hwo9g6r77h2EF1/Xk1oKOIOmnAkgtv41LPXg37fp2dlr45C8qCA9/8zrcc9F5zr2JT0eVPTrh5aahl"...>>}
9> timer:tc(base64, encode, [Data]).
{656,
 <<"za4NqWGfbqFHK+KZKmXzUwtgF6H9+4Hwo9g6r77h2EF1/Xk1oKOIOmnAkgtv41LPXg37fp2dlr45C8qCA9/8zrcc9F5zr2JT0eVPTrh5aahl"...>>}

being deleted which led to the node not being able to create
               any more ETS tables if queries were made to many number of
               webservers. ibrowse now deletes the ETS table it creates once the
               last connection to a webserver is dropped.
               Reported by Seth Falcon.
             * Spurious data being returned at end of body in certain cases of
               chunked encoded responses from the server.
               Reported by Chris Newcombe.