Support for Jebena Trace ID; fix for Python2 Logging setups

[jpotter]

This fixes #16 (for a second time) and addresses #18.

Python Logging

The issue appears to be related to python2 envs that already have logging configured. After some investigation, the cleanest way I can find to check this condition is to see if the root logger has any handlers attached to it (i.e. stream writers or file writers). If no handlers; logging not configured.

This PR updates the client to call a function, __get_logger, that can lazy-load the logger and configure it accordingly. This allows the jebenaclient to be imported before other parts of the python system may have triggered their logging config.

Jebena Trace ID

Developers wanting to fetch the Jebena Trace ID of the most recent call to run_query() can now do so by calling jebenaclient.get_last_run_trace_id() -- simple enough. This should work after a failed GQL call as well, i.e. calling something like this:

import jebenaclient
try:
   jebenaclient.run_query("some bad query")
except jebenaclient.JebenaCliGQLException:
   print("Failed to run query for trace id %s" % jebenaclient.get_last_run_trace_id())

yields this -- note the very last line.

ERROR:jebenaclient:GQL response includes an error. Part of the query may have succeeded.
 *** The original query was:
'some bad query'

 *** The full response was:
{   u'data': None,
    u'errors': [   {   u'locations': [{   u'column': 1, u'line': 1}],
                       u'message': u'Syntax Error GraphQL (1:1) Unexpected Name "some"\n\n1: some bad query\n   ^\n'}]}


ERROR:jebenaclient: *** GQL error #1: Syntax Error GraphQL (1:1) Unexpected Name "some"

1: some bad query
   ^

ERROR:jebenaclient:For GraphQL schema, see Docs tab at https://staging.api.enveritas.net/v1/docs/graphiql
Failed to run query for trace id J-2ddadfe8-4732-01750

[bretty-mcbrettface]

are we sure this is going to work? i think last time we tried basicConfig it overrode all my custom logger stuff. @jpotter

[jpotter]

logging.getLogger().handlers should be non-empty if you have any custom loggers installed. This code only gets triggered after a call to run_query() is triggered, so as long as you've configured your loggers before executing the client, it should be safe.

In theory. In practice, there might be something I've missed here, though -- let me know how it works for you?