reduce logging level for timeouts

[alexeyOnGitHub]

this change is related to #67

the motivation for this change is that some users may have external
retriers around clients, like this Memcached one.
the library ideally should throw an exception on timeout and
let users deal with it however they see fit - it may be logging,
retrying or falling back to another solution.
when the library logs an error in this case, this makes logging
noisy, which may distort operational metrics in a
typical prod environment.

[coveralls]

Coverage remained the same at ?% when pulling e461432 on alexeyOnGitHub:ask-reduce-logging into f69d98f on spotify:master.

[spkrka]

Thanks for the PR! I am not sure this is something that we want to do.

First of all - how noisy is this in practice? It should only log once if memcached becomes very slow (doesn't make forward progress at all during the period (default 3 seconds)).

Second of all, users of this could configure their logging to filter out this message if it is too annoying.
For logback, that would look something like:

<logger name="com.spotify.folsom.client.DefaultRawMemcacheClient" level="OFF"/>

Also, I think error better captures the semantic meaning of the log event compared to info.
(Though perhaps warn would still make sense)

[alexeyOnGitHub]

we need to provide multiple 9s of availability together with pretty low latency,
so we use very aggressive timeouts for Memcached calls and then automatically fall back to another level of caching. this happens pretty often in our case, at least in highly loaded services.
I don't want to completely disable logging for this client. ideally I would want to be able to attach my logic (via a listener or something similar) to this condition and process it myself.
we forked the library and disabled extra logging for now, feel free to close this PR