More verbosity on exceptions

[fcracker79]

Upon digging into bug #1837, I have created a pull request to improve errors verbosity.
Simply put, it logs stacktrace in case of errors.

---

This change is 

[jeffwidman]

@dpkp / @tvoinarovskyi your thoughts here?

Some of these look useful, some not so much (ie, I'd be hesitant to replace the pass one, as that looks intentional)

[fcracker79]

@jeffwidman the only pass that has been replaced with a log is at kafka/client_async.py:647. That is the point where I fall into when experiencing the issue #1837, which is the reason why I opened this PR. By removing it, it would be impossible to dig into the socket.error issue and this PR would not help with #1837.

[tvoinarovskyi]

I feel like having tracebacks on those errors are not too useful. Logs are quite unique and you can find the point it fails on relatively easy. In logging, you can format the log to include the source line without the need to print tracebacks.

As for replacing the "pass", it seems like the case is critical and should not be triggered in a normal workflow, so printing that exception actually may help. I'm ok with adding it. Although the message might be something more descriptive: "In-flight requests remain on a close connection. Socket error:"

[fcracker79]

@tvoinarovskyi thanks for your response.

My original idea was to get that stacktrace to understand where it fails whenever it happens and, more importantly, where it retries without appropriate error management (please see #1837).
By adding such verbosity it would have been relatively easy to implement another PR to fix the above issue.

Concerning the "pass", not being part of the normal workflow could be a good reason to log it, as it should not happen so frequently. It may be the case that a normal user could understand the root cause of such error messages and fix it (closed ports, firewalls that screw up the the network traffic, persistent connections killed by external actors...). The additional descriptive message could help. Does it fail for the fact that "In-flight requests remain on a close connection"? Or there are other cases? If so, do we have, at that level, enough information do be more descriptive? I am new with this project, so I do not know, but that stacktrace could help me much about the nature of such errors. :-)

[dpkp]

How about adding an optional configuration parameter that would enable exc_info=True wherever appropriate? This would make this feature useful as an opt-in debugging mechanism, while not polluting the logs of folks that aren't interested in the additional context.

[jeffwidman]

@fcracker79 care to rebase? Note that due to #1193 the codebase shed a lot of old deprecated code, so that may slim this down a bit as well...